# drafts

name: draft-beyer-agent-identity-problem-statement
rev: 00
title: Problem Statement for Human-Anchored Agent Identity, Delegation, and Provenance
time: 2026-04-01T08:08:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-03T08:08:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:41.698294+00:00
source: ietf
abstract:
  Software agents now act on behalf of people across communication,
     automation, and decision-making contexts.  These agents increasingly
     initiate actions, delegate tasks, and interact with other agents
     without a clear, durable, or verifiable connection to the human who
     authorized them.  Existing identity systems authenticate software,
     but they do not provide a model for human anchoring, scoped
     delegation, or provenance across agent ecosystems.

     This document describes the problem space for human-anchored agent
     identity.  It outlines the gaps in current identity mechanisms, the
     risks created by uncontrolled replication and impersonation, and the
     need for a consistent architectural model that preserves human
     authority, supports explicit delegation, and maintains verifiable
     provenance across contexts.

     This document does not define a protocol.  It defines the problem
     that an architectural model must address in order to support safe,
     accountable, and interoperable agent ecosystems.

full_text:
  Network Working Group                                        B. W. Beyer
  Internet-Draft                                               Independent
  Intended status: Informational                              1 April 2026
  Expires: 3 October 2026


    Problem Statement for Human-Anchored Agent Identity, Delegation, and
                                 Provenance
              draft-beyer-agent-identity-problem-statement-00

  Abstract

     Software agents now act on behalf of people across communication,
     automation, and decision-making contexts.  These agents increasingly
     initiate actions, delegate tasks, and interact with other agents
     without a clear, durable, or verifiable connection to the human who
     authorized them.  Existing identity systems authenticate software,
     but they do not provide a model for human anchoring, scoped
     delegation, or provenance across agent ecosystems.

     This document describes the problem space for human-anchored agent
     identity.  It outlines the gaps in current identity mechanisms, the
     risks created by uncontrolled replication and impersonation, and the
     need for a consistent architectural model that preserves human
     authority, supports explicit delegation, and maintains verifiable
     provenance across contexts.

     This document does not define a protocol.  It defines the problem
     that an architectural model must address in order to support safe,
     accountable, and interoperable agent ecosystems.

  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 3 October 2026.




  Beyer                    Expires 3 October 2026                 [Page 1]


  Internet-Draft      Agent Identity Problem Statement          April 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Problem Dimensions  . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Lack of Human Anchoring . . . . . . . . . . . . . . . . .   3
       2.2.  Unscoped or Implicit Delegation . . . . . . . . . . . . .   4
       2.3.  Uncontrolled Replication  . . . . . . . . . . . . . . . .   4
       2.4.  Loss of Provenance  . . . . . . . . . . . . . . . . . . .   4
       2.5.  Fragmented Interoperability . . . . . . . . . . . . . . .   4
       2.6.  Resulting Risks . . . . . . . . . . . . . . . . . . . . .   4
     3.  Current Limitations . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Identity Systems Do Not Bind Agents to Humans . . . . . .   5
       3.2.  Delegation Is Implicit, Local, or Application-Specific  .   5
       3.3.  Replication Lacks Lineage or Control  . . . . . . . . . .   5
       3.4.  Provenance Is Not Preserved Across Contexts . . . . . . .   5
       3.5.  Interoperability Is Fragmented  . . . . . . . . . . . . .   6
       3.6.  Security and Accountability Are Incomplete  . . . . . . .   6
     4.  Security and Privacy Considerations . . . . . . . . . . . . .   6
       4.1.  Impersonation and Misrepresentation . . . . . . . . . . .   6
       4.2.  Unauthorized Replication  . . . . . . . . . . . . . . . .   7
       4.3.  Loss of Provenance  . . . . . . . . . . . . . . . . . . .   7
       4.4.  Privacy Risks . . . . . . . . . . . . . . . . . . . . . .   7
       4.5.  Fragmentation Across Ecosystems . . . . . . . . . . . . .   7
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
     7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     Software agents now participate directly in communication,
     automation, and decision-making on behalf of people.  These agents
     draft messages, initiate transactions, negotiate with other agents,
     and perform tasks that previously required direct human action.  As
     their capabilities expand, agents increasingly act without continuous
     human supervision, and they interact with other agents across diverse
     platforms and ecosystems.



  Beyer                    Expires 3 October 2026                 [Page 2]


  Internet-Draft      Agent Identity Problem Statement          April 2026


     Existing identity systems authenticate software components, devices,
     or network endpoints, but they do not provide a consistent way to
     represent the human who authorized an agent, the scope of authority
     granted to that agent, or the provenance of actions taken by that
     agent over time.  As a result, agent-to-agent interactions lack a
     durable, verifiable connection to the human identity that ultimately
     bears responsibility.

     This gap creates risks.  Agents can be replicated without constraint,
     delegated without transparency, or operated without a clear chain of
     accountability.  Without a model for human anchoring, delegation, and
     provenance, ecosystems cannot reliably determine whether an agent is
     acting within its intended authority or whether an action can be
     traced back to a responsible human.

     This document describes the problem space for human-anchored agent
     identity.  It identifies the structural gaps in current identity
     mechanisms, outlines the risks created by uncontrolled agent
     replication and impersonation, and motivates the need for an
     architectural model that preserves human authority while enabling
     safe, interoperable agent ecosystems.

     This document does not define a protocol.  It defines the problem
     that an architectural model must address in order to support
     accountable, verifiable, and human-aligned agent behavior across
     platforms and contexts.

  2.  Problem Dimensions

     The challenges of human-anchored agent identity arise from several
     structural gaps in current identity systems.  These gaps are not
     limited to any single platform or ecosystem; they reflect a broader
     absence of a model that connects human authority to autonomous or
     semi-autonomous software behavior.  The following dimensions
     illustrate the scope of the problem.

  2.1.  Lack of Human Anchoring

     Most identity systems authenticate software components, devices, or
     network endpoints.  They do not provide a durable representation of
     the human who authorized an agent or the scope of authority granted
     to that agent.  As a result, an agent may act without a verifiable
     link to a responsible human, and ecosystems cannot reliably determine
     whether an action reflects human intent.







  Beyer                    Expires 3 October 2026                 [Page 3]


  Internet-Draft      Agent Identity Problem Statement          April 2026


  2.2.  Unscoped or Implicit Delegation

     Agents frequently act on delegated authority, but current systems do
     not provide a consistent way to express the scope, duration, or
     conditions of that delegation.  Delegation is often implicit,
     inferred from context, or embedded in application-specific logic.
     Without explicit, portable delegation semantics, ecosystems cannot
     determine whether an agent is acting within its intended authority.

  2.3.  Uncontrolled Replication

     Agents can be copied, instantiated, or replicated across platforms
     without any mechanism to track their lineage or relationship to the
     human who originally authorized them.  This creates uncertainty about
     which instances are legitimate, which are outdated, and which may
     have been created without consent.  Without a model for controlled
     replication, ecosystems cannot distinguish authorized agents from
     unauthorized copies.

  2.4.  Loss of Provenance

     As agents act across contexts, the provenance of their actions is
     often lost.  Systems may record that an action was taken by a
     software component, but not which human authorized the agent, which
     delegation chain applied, or whether the agent was operating within
     its intended scope.  Without durable provenance, accountability
     becomes difficult or impossible.

  2.5.  Fragmented Interoperability

     Identity systems vary widely across platforms, and no common model
     exists for representing human anchoring, delegation, or provenance in
     a way that can be understood across ecosystems.  As agents interact
     across organizational and technical boundaries, the absence of a
     shared architectural model leads to inconsistent assumptions,
     incompatible representations, and gaps in accountability.

  2.6.  Resulting Risks

     These structural gaps create risks for users, platforms, and
     ecosystems.  Agents may act without clear authority, impersonate
     other agents, or be replicated without consent.  Actions may lack
     verifiable provenance, making it difficult to determine
     responsibility or detect misuse.  Without a model that connects human
     identity to agent behavior, ecosystems cannot ensure that agents act
     in ways that reflect human intent.





  Beyer                    Expires 3 October 2026                 [Page 4]


  Internet-Draft      Agent Identity Problem Statement          April 2026


  3.  Current Limitations

     The structural gaps described in Section 2 manifest across existing
     identity systems in ways that limit their ability to support
     human-anchored agent ecosystems.  These limitations are not the
     result of flaws in any particular technology; rather, they reflect
     the absence of a shared model for connecting human authority, agent
     behavior, and verifiable provenance across contexts.  Existing
     identity systems are not designed to support the emerging reality of
     autonomous and semi-autonomous agents acting on behalf of people, and
     a consistent architectural model is needed to preserve human
     authority, express delegation, and maintain verifiable provenance.

  3.1.  Identity Systems Do Not Bind Agents to Humans

     Most identity systems authenticate software components, devices, or
     network endpoints.  They do not provide a durable representation of
     the human who authorized an agent or the scope of authority granted
     to that agent.  As a result, an authenticated agent may act without a
     verifiable link to a responsible human, and ecosystems cannot
     determine whether an action reflects human intent.

  3.2.  Delegation Is Implicit, Local, or Application-Specific

     Delegation is often encoded in application logic, embedded in access
     tokens, or inferred from context.  These representations are not
     portable across ecosystems and do not express the scope, duration, or
     conditions of authority.  Without explicit, interoperable delegation
     semantics, systems cannot determine whether an agent is acting within
     its intended authority or whether a delegation chain remains valid.

  3.3.  Replication Lacks Lineage or Control

     Agents can be copied, instantiated, or replicated across platforms
     without any mechanism to track their lineage or relationship to the
     human who originally authorized them.  Existing identity systems do
     not distinguish between authorized instances and unauthorized copies,
     nor do they provide a way to express which instances remain valid
     over time.  This creates uncertainty about which agents should be
     trusted.

  3.4.  Provenance Is Not Preserved Across Contexts

     Systems may record that an action was taken by a software component,
     but they rarely preserve the delegation chain, the human identity
     root, or the conditions under which the agent was authorized.  As
     agents move across platforms, this provenance is often lost, making
     it difficult to determine responsibility or detect misuse.



  Beyer                    Expires 3 October 2026                 [Page 5]


  Internet-Draft      Agent Identity Problem Statement          April 2026


  3.5.  Interoperability Is Fragmented

     Identity systems vary widely in how they represent software identity,
     authorization, and delegation.  No common architectural model exists
     for expressing human anchoring, delegation semantics, or provenance
     in a way that can be understood across ecosystems.  As agents
     interact across organizational and technical boundaries, these
     inconsistencies lead to gaps in accountability and incompatible
     assumptions about authority.

  3.6.  Security and Accountability Are Incomplete

     Without a model that connects human identity to agent behavior,
     ecosystems cannot reliably determine whether an agent is acting
     within its intended authority, whether a delegation chain remains
     valid, or whether an action can be traced back to a responsible
     human.  This limits the ability of platforms to detect impersonation,
     prevent unauthorized replication, or enforce accountability across
     agent interactions.

  4.  Security and Privacy Considerations

     The absence of a consistent model for human-anchored agent identity
     creates security and privacy risks across ecosystems.  These risks
     arise not from any single technology, but from the structural gaps
     described in this document.  Without a way to connect agent behavior
     to human authority, systems cannot reliably determine whether an
     agent is legitimate, whether it is acting within its intended scope,
     or whether its actions can be traced to a responsible human.  Current
     identity systems do not provide the security or privacy properties
     needed for autonomous and semi-autonomous agents acting on behalf of
     people; a consistent architectural model is required to preserve
     human authority, express delegation, and maintain verifiable
     provenance while avoiding unnecessary linkability or cross-context
     correlation.

  4.1.  Impersonation and Misrepresentation

     Agents may impersonate other agents or present themselves as acting
     on behalf of a human without a verifiable link to that human.
     Existing identity systems authenticate software components but do not
     express the human identity root or the delegation chain that
     authorized the agent.  This makes it difficult to detect
     impersonation or determine whether an agent is acting legitimately.







  Beyer                    Expires 3 October 2026                 [Page 6]


  Internet-Draft      Agent Identity Problem Statement          April 2026


  4.2.  Unauthorized Replication

     Agents can be copied or instantiated without the knowledge or consent
     of the human who originally authorized them.  Without a model for
     lineage or controlled replication, ecosystems cannot distinguish
     authorized instances from unauthorized copies, nor can they determine
     which instances remain valid over time.  This creates opportunities
     for misuse, fraud, or unbounded agent proliferation.

  4.3.  Loss of Provenance

     As agents act across platforms, the provenance of their actions is
     often lost.  Systems may record that an action was taken by a
     software component, but not which human authorized the agent, which
     delegation chain applied, or whether the agent was operating within
     its intended scope.  Without durable provenance, accountability
     becomes difficult, and misuse may go undetected.

  4.4.  Privacy Risks

     In the absence of a consistent architectural model, ecosystems may
     rely on ad-hoc identifiers, cross-context correlation, or
     platform-specific tracking to infer relationships between humans and
     agents.  These practices can erode privacy, create unnecessary
     linkability, or expose sensitive information about human behavior.  A
     model that preserves human authority must also avoid introducing
     global identifiers or mechanisms that enable cross-context tracking.

  4.5.  Fragmentation Across Ecosystems

     Because identity systems vary widely, agents may be interpreted
     differently across platforms, leading to inconsistent assumptions
     about authority, delegation, and provenance.  This fragmentation
     increases the likelihood of security gaps, misconfigurations, or
     unintended privilege escalation as agents move across organizational
     boundaries.

  5.  IANA Considerations

     This document has no IANA actions.

  6.  Normative References

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





  Beyer                    Expires 3 October 2026                 [Page 7]


  Internet-Draft      Agent Identity Problem Statement          April 2026


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

  7.  Informative References

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

     [RFC7643]  Hunt, P., Ansari, A., Sanchez, M., and K. McCloghrie,
                "System for Cross-domain Identity Management: Core
                Schema", RFC 7643, 2015,
                <https://www.rfc-editor.org/rfc/rfc7643>.

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

  Author's Address

     Brandon Wesley Beyer
     Independent
     Email: brandnbyr@icloud.com




























  Beyer                    Expires 3 October 2026                 [Page 8]


name: draft-beyer-agent-identity-architecture
rev: 00
title: Architecture for Human-Anchored Agent Identity, Delegation, and Provenance
time: 2026-04-01T08:11:35Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-03T08:11:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:41.698299+00:00
source: ietf
abstract:
  Software agents increasingly act on behalf of people across
     communication, automation, and decision-making contexts.  These
     agents initiate actions, delegate tasks, and interact with other
     agents without a consistent model for representing the human who
     authorized them, the scope of authority they possess, or the
     provenance of their actions across ecosystems.

     This document defines an architectural model for human-anchored agent
     identity.  The model introduces a human identity root, explicit
     delegation semantics, and a provenance structure that enables
     ecosystems to determine whether an agent is legitimate, whether it is
     acting within its intended authority, and how its actions relate to a
     responsible human.

     This document does not define a protocol or wire format.  It provides
     an architectural foundation that existing systems may bind to in
     order to support accountable, interoperable, and human-aligned agent
     ecosystems.

full_text:
  Network Working Group                                        B. W. Beyer
  Internet-Draft                                               Independent
  Intended status: Informational                              1 April 2026
  Expires: 3 October 2026


      Architecture for Human-Anchored Agent Identity, Delegation, and
                                 Provenance
                 draft-beyer-agent-identity-architecture-00

  Abstract

     Software agents increasingly act on behalf of people across
     communication, automation, and decision-making contexts.  These
     agents initiate actions, delegate tasks, and interact with other
     agents without a consistent model for representing the human who
     authorized them, the scope of authority they possess, or the
     provenance of their actions across ecosystems.

     This document defines an architectural model for human-anchored agent
     identity.  The model introduces a human identity root, explicit
     delegation semantics, and a provenance structure that enables
     ecosystems to determine whether an agent is legitimate, whether it is
     acting within its intended authority, and how its actions relate to a
     responsible human.

     This document does not define a protocol or wire format.  It provides
     an architectural foundation that existing systems may bind to in
     order to support accountable, interoperable, and human-aligned agent
     ecosystems.

  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 3 October 2026.




  Beyer                    Expires 3 October 2026                 [Page 1]


  Internet-Draft         Agent Identity Architecture            April 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Core Identity Model . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Human Identity Root . . . . . . . . . . . . . . . . . . .   4
       2.2.  Agent Identity  . . . . . . . . . . . . . . . . . . . . .   5
       2.3.  Delegation Semantics  . . . . . . . . . . . . . . . . . .   5
       2.4.  Relationships Among Core Constructs . . . . . . . . . . .   5
     3.  Delegation Chains . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Structure of a Delegation Chain . . . . . . . . . . . . .   6
       3.2.  Scope and Constraints . . . . . . . . . . . . . . . . . .   6
       3.3.  Nested Delegation . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.5.  Properties of Delegation Chains . . . . . . . . . . . . .   8
     4.  Constitutional Contracts  . . . . . . . . . . . . . . . . . .   9
       4.1.  Role of Constitutional Contracts  . . . . . . . . . . . .   9
       4.2.  Scope of a Constitutional Contract  . . . . . . . . . . .   9
       4.3.  Portability Across Ecosystems . . . . . . . . . . . . . .  10
       4.4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.  Replication and Provenance  . . . . . . . . . . . . . . . . .  11
       5.1.  Replication Model . . . . . . . . . . . . . . . . . . . .  11
       5.2.  Constraints on Replication  . . . . . . . . . . . . . . .  12
       5.3.  Provenance Model  . . . . . . . . . . . . . . . . . . . .  12
       5.4.  Portability Across Contexts . . . . . . . . . . . . . . .  13
       5.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.  Interaction Model . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.  Roles in the Interaction Model  . . . . . . . . . . . . .  13
       6.2.  Authority in Interactions . . . . . . . . . . . . . . . .  14
       6.3.  Cross-Context Interactions  . . . . . . . . . . . . . . .  15
       6.4.  Agent-to-Agent Interactions . . . . . . . . . . . . . . .  15
       6.5.  Human-Agent Interactions  . . . . . . . . . . . . . . . .  15
       6.6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.  Interoperability with Existing Systems  . . . . . . . . . . .  16
       7.1.  Binding to Existing Identity Systems  . . . . . . . . . .  16
       7.2.  Integration with Authorization Frameworks . . . . . . . .  16
       7.3.  Use with Credential and Key Systems . . . . . . . . . . .  17



  Beyer                    Expires 3 October 2026                 [Page 2]


  Internet-Draft         Agent Identity Architecture            April 2026


       7.4.  Cross-Context Interpretation  . . . . . . . . . . . . . .  17
       7.5.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  17
       7.6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.  Security and Privacy Considerations . . . . . . . . . . . . .  18
       8.1.  Human Anchoring . . . . . . . . . . . . . . . . . . . . .  18
       8.2.  Delegation Integrity  . . . . . . . . . . . . . . . . . .  18
       8.3.  Replication Risks . . . . . . . . . . . . . . . . . . . .  18
       8.4.  Provenance Risks  . . . . . . . . . . . . . . . . . . . .  19
       8.5.  Privacy Considerations  . . . . . . . . . . . . . . . . .  19
       8.6.  Ecosystem Fragmentation . . . . . . . . . . . . . . . . .  19
       8.7.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  19
     11. Informative References  . . . . . . . . . . . . . . . . . . .  20
     Appendix A.  Figures  . . . . . . . . . . . . . . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     Software agents increasingly act on behalf of people across
     communication, automation, and decision-making contexts.  These
     agents initiate actions, delegate tasks, and interact with other
     agents without continuous human supervision.  As their capabilities
     expand, ecosystems require a consistent way to determine whether an
     agent is legitimate, whether it is acting within its intended
     authority, and how its actions relate to a responsible human.

     Existing identity systems authenticate software components, devices,
     or network endpoints, but they do not provide a durable
     representation of the human who authorized an agent or the delegation
     chain that governs its behavior.  They also do not preserve
     provenance as agents move across platforms.  These gaps limit
     accountability, create opportunities for impersonation or
     unauthorized replication, and make it difficult for ecosystems to
     reason about agent behavior in a consistent way.

     This document defines an architectural model for human-anchored agent
     identity.  The model introduces three core elements: a human identity
     root that represents the responsible human; explicit delegation
     semantics that express the scope and conditions of authority; and a
     provenance structure that enables ecosystems to understand how an
     agent's actions relate to a responsible human across contexts.









  Beyer                    Expires 3 October 2026                 [Page 3]


  Internet-Draft         Agent Identity Architecture            April 2026


     The architecture is transport-agnostic and does not define a protocol
     or wire format.  Instead, it provides a conceptual foundation that
     existing systems may bind to in order to support accountable,
     interoperable, and human-aligned agent ecosystems.  The model is
     intended to complement, not replace, existing identity and
     authorization mechanisms.

     The goal of this document is to provide a consistent architectural
     framework that preserves human authority, enables explicit
     delegation, and maintains verifiable provenance across agent
     interactions, while avoiding global identifiers or mechanisms that
     enable cross-context tracking.

  2.  Core Identity Model

     The architectural model for human-anchored agent identity is built on
     three foundational constructs: a human identity root that represents
     the responsible human; an agent identity that represents a software
     agent acting on behalf of that human; and explicit delegation
     semantics that express the scope and conditions under which the agent
     is authorized to act.  These constructs provide a consistent way for
     ecosystems to understand how agent behavior relates to human
     authority across contexts.

             +----------------------+
             |  Human Identity Root |
             +----------------------+
                       |
                       v
             (Anchors all delegation)

                         Figure 1: Human Identity Root

  2.1.  Human Identity Root

     The human identity root represents the human who ultimately bears
     responsibility for an agent's actions.  It is an architectural role,
     not a global identifier or account.  The human identity root provides
     a stable point of reference for delegation chains and provenance,
     enabling ecosystems to determine which human authorized an agent
     without requiring cross-context tracking or universal identifiers.

     The architecture does not prescribe how the human identity root is
     instantiated, stored, or authenticated.  It may be bound to existing
     identity systems, credentials, or verification mechanisms, provided
     that the binding preserves privacy and avoids unnecessary linkability
     across contexts.




  Beyer                    Expires 3 October 2026                 [Page 4]


  Internet-Draft         Agent Identity Architecture            April 2026


  2.2.  Agent Identity

     An agent identity represents a software agent acting on behalf of a
     human.  It is distinct from the human identity root and expresses the
     agent's role, capabilities, and relationship to the human who
     authorized it.  An agent identity may be instantiated multiple times,
     provided that each instance can be related to the human identity root
     through a delegation chain.

     The architecture does not define a credential format, key structure,
     or transport mechanism for agent identities.  Instead, it provides a
     conceptual model that existing systems may bind to in order to
     represent agents in a consistent and interoperable way.

             +----------------------+
             |    Agent Identity    |
             +----------------------+
                       |
                       v
             (Acts on behalf of human)

                            Figure 2: Agent Identity

  2.3.  Delegation Semantics

     Delegation semantics express the scope, duration, and conditions
     under which an agent is authorized to act on behalf of a human.
     Delegation is explicit and portable across contexts, enabling
     ecosystems to determine whether an agent is acting within its
     intended authority and whether a delegation chain remains valid over
     time.

     Delegation semantics do not prescribe a protocol or wire format.
     They define the architectural properties that a delegation
     representation must support, including the ability to express scope,
     constraints, and revocation at the delegation-chain level rather than
     at the transport level.

  2.4.  Relationships Among Core Constructs

     The human identity root, agent identity, and delegation semantics
     form a coherent model that enables ecosystems to understand how agent
     behavior relates to human authority.  The human identity root anchors
     the delegation chain; the delegation semantics express the conditions
     of authority; and the agent identity represents the software agent
     acting under that authority.  Together, these constructs provide a
     foundation for accountability, interoperability, and provenance
     across agent ecosystems.



  Beyer                    Expires 3 October 2026                 [Page 5]


  Internet-Draft         Agent Identity Architecture            April 2026


  3.  Delegation Chains

     Delegation chains express how authority flows from a responsible
     human to one or more software agents.  A delegation chain begins at
     the human identity root and proceeds through one or more delegation
     steps, each of which grants a specific scope of authority to an
     agent.  Delegation chains provide ecosystems with a consistent way to
     determine whether an agent is legitimate, whether it is acting within
     its intended authority, and how its actions relate to a responsible
     human across contexts.

  3.1.  Structure of a Delegation Chain

     A delegation chain consists of a sequence of delegation steps, each
     of which expresses a grant of authority from one entity to another.
     The first step originates at the human identity root, and subsequent
     steps may delegate authority to additional agents.  Each step
     expresses the scope, duration, and conditions under which the
     delegated authority is valid.

     Delegation steps are explicit and portable across contexts.  They do
     not rely on application-specific logic or implicit assumptions about
     authority.  This enables ecosystems to interpret delegation chains
     consistently, even when agents move across organizational or
     technical boundaries.

  3.2.  Scope and Constraints

     Each delegation step expresses the scope of authority granted to an
     agent.  Scope may include the types of actions the agent is permitted
     to perform, the contexts in which those actions are valid, or other
     constraints that limit the agent's authority.  Delegation steps may
     also express temporal constraints, such as expiration or duration.

     The architecture does not prescribe a specific representation for
     scope or constraints.  Instead, it defines the architectural
     properties that a scope representation must support, including the
     ability to express limitations, conditions, and revocation in a way
     that is interpretable across contexts.












  Beyer                    Expires 3 October 2026                 [Page 6]


  Internet-Draft         Agent Identity Architecture            April 2026


        Human Identity Root
                 |
                 v
        +----------------------+
        | Delegation Semantics |
        +----------------------+
                 |
                 v
             Agent Identity

                         Figure 3: Delegation Semantics

  3.3.  Nested Delegation

     Delegation chains may include nested delegation, in which an agent
     that has been granted authority may delegate a subset of that
     authority to another agent.  Nested delegation enables complex agent
     ecosystems while preserving accountability and traceability to the
     human identity root.

        Human Identity Root
                 |
                 v
          Delegation Step 1
                 |
                 v
             Agent A
                 |
                 v
          Delegation Step 2 (subset)
                 |
                 v
             Agent B

                          Figure 4: Nested Delegation

     The architecture does not require nested delegation, but it supports
     it as a natural extension of the delegation model.  Each nested
     delegation step must remain within the scope of the authority granted
     by the preceding step.

  3.4.  Revocation

     Revocation applies at the delegation-chain level rather than at the
     transport level.  A delegation step may be revoked by the entity that
     issued it, and revocation invalidates all subsequent steps in the
     chain.  This enables ecosystems to determine whether a delegation
     chain remains valid without relying on transport-specific mechanisms.



  Beyer                    Expires 3 October 2026                 [Page 7]


  Internet-Draft         Agent Identity Architecture            April 2026


        Human Identity Root
                 |
                 v
          Delegation Step 1 ----X (revoked)
                 |
                 v
          Delegation Step 2 (invalid)
                 |
                 v
               Agent (invalid)

                           Figure 5: Revocation Flow

     The architecture does not define a protocol for distributing
     revocation information.  It defines the conceptual model in which
     revocation is expressed and interpreted.

  3.5.  Properties of Delegation Chains

     Delegation chains provide several architectural properties that
     support accountable and interoperable agent ecosystems:

        Human Identity Root
                 |
                 v
          Delegation Step 1
                 |
                 v
          Delegation Step 2
                 |
                 v
               Agent

                      Figure 6: Delegation Chain Structure

     *  *Explicitness* — Delegation is expressed explicitly rather than
        inferred from context or application logic.

     *  *Portability* — Delegation chains can be interpreted across
        ecosystems without relying on platform-specific assumptions.

     *  *Traceability* — Each step in the chain can be related to the
        human identity root, enabling accountability.

     *  *Scoping* — Delegation steps express the scope and conditions of
        authority in a consistent way.





  Beyer                    Expires 3 October 2026                 [Page 8]


  Internet-Draft         Agent Identity Architecture            April 2026


     *  *Revocability* — Delegation steps can be revoked, and revocation
        invalidates subsequent steps in the chain.

        Delegation Step
             |
             +-- Scope: Actions permitted
             +-- Context: Where valid
             +-- Time: Duration/expiry
             +-- Conditions: Additional limits

                        Figure 7: Scope and Constraints

     These properties enable ecosystems to reason about agent authority in
     a consistent and interoperable way, even as agents move across
     platforms or interact with other agents.

  4.  Constitutional Contracts

     Constitutional contracts define the governance layer that constrains
     how agents may act on behalf of a human.  They express the durable,
     high-level conditions under which authority may be delegated,
     exercised, or revoked.  Constitutional contracts do not describe
     runtime behavior, enforcement mechanisms, or policy languages.
     Instead, they provide an architectural boundary that ensures agent
     behavior remains anchored to human intent.

  4.1.  Role of Constitutional Contracts

     A constitutional contract establishes the foundational rules that
     govern the relationship between a human identity root and the agents
     acting on its behalf.  These rules define the permissible structure
     of delegation chains, the constraints on agent authority, and the
     conditions under which revocation or modification may occur.  The
     contract provides a stable reference point that ecosystems can rely
     on when interpreting agent behavior across contexts.

     The constitutional contract is not a protocol artifact.  It is an
     architectural construct that informs how systems reason about
     authority, delegation, and provenance without prescribing how these
     concepts are encoded or transmitted.

  4.2.  Scope of a Constitutional Contract

     A constitutional contract expresses durable constraints on agent
     authority.  These constraints may include:

     *  *Structural constraints* — rules governing the shape and depth of
        delegation chains.



  Beyer                    Expires 3 October 2026                 [Page 9]


  Internet-Draft         Agent Identity Architecture            April 2026


     *  *Authority constraints* — limits on the types of actions an agent
        may perform or the contexts in which those actions are valid.

     *  *Revocation constraints* — conditions under which authority may be
        withdrawn and how revocation affects downstream delegation steps.

     *  *Replication constraints* — rules governing when and how agents
        may be instantiated or replicated.

     These constraints provide ecosystems with a consistent way to
     interpret agent authority without requiring global identifiers or
     cross-context tracking.

  4.3.  Portability Across Ecosystems

     Constitutional contracts are portable across platforms and
     ecosystems.  They do not rely on platform-specific semantics or
     enforcement mechanisms.  This portability enables agents to operate
     across organizational boundaries while preserving the architectural
     guarantees of human anchoring, explicit delegation, and durable
     provenance.

     The architecture does not prescribe how constitutional contracts are
     stored, distributed, or validated.  It defines the conceptual
     properties that a contract must support in order to remain
     interpretable across contexts.

  4.4.  Non-Goals

     Constitutional contracts are not intended to serve as:

     *  *Policy engines* — they do not define runtime decision logic.

     *  *Protocol elements* — they do not specify message formats or
        transport semantics.

     *  *Cryptographic frameworks* — they do not select algorithms or key
        structures.

     *  *Behavioral safety systems* — they do not govern agent cognition
        or internal decision-making.

     These non-goals ensure that constitutional contracts remain an
     architectural governance layer rather than an operational mechanism.







  Beyer                    Expires 3 October 2026                [Page 10]


  Internet-Draft         Agent Identity Architecture            April 2026


  4.5.  Summary

     Constitutional contracts provide the durable governance structure
     that binds human authority to agent behavior.  They define the
     architectural boundaries within which delegation, replication, and
     provenance operate, enabling ecosystems to interpret agent actions
     consistently without imposing protocol semantics or platform-specific
     assumptions.

  5.  Replication and Provenance

     Replication and provenance describe how agent instances relate to one
     another and how their actions can be traced back to a responsible
     human.  Replication refers to the creation of new agent instances,
     whether through copying, instantiation, or migration across
     platforms.  Provenance refers to the durable record of how an agent's
     authority, identity, and actions relate to the human identity root
     and the delegation chain that authorized them.

  5.1.  Replication Model

     Agents may be instantiated or replicated across platforms in order to
     perform tasks, operate in different environments, or maintain
     continuity of service.  The architecture treats replication as an
     expected property of agent ecosystems, provided that each replicated
     instance can be related to the human identity root through a valid
     delegation chain.

             Agent Identity
                   |
           +-------+-------+
           |               |
           v               v
       Instance A      Instance B
           |               |
           +-------+-------+
                   |
                   v
           Both trace to same
           Human Identity Root

                          Figure 8: Replication Model

     The architecture does not prescribe how replication occurs or how
     instances are created.  Instead, it defines the conceptual
     requirement that replicated agents must remain within the scope of
     the authority granted by the human identity root and must maintain a
     verifiable relationship to the delegation chain that authorized them.



  Beyer                    Expires 3 October 2026                [Page 11]


  Internet-Draft         Agent Identity Architecture            April 2026


  5.2.  Constraints on Replication

     Replication is constrained by the constitutional contract and the
     delegation semantics that govern agent authority.  These constraints
     may limit the number of instances, the contexts in which replication
     is permitted, or the scope of authority available to replicated
     agents.  Replication must not create new authority; it may only
     reproduce authority that has already been granted.

     These constraints ensure that replication does not expand an agent's
     authority beyond what the human identity root intended and that
     ecosystems can distinguish authorized instances from unauthorized
     copies.

  5.3.  Provenance Model

     Provenance provides a durable record of how an agent's actions relate
     to the human identity root and the delegation chain that authorized
     them.  Provenance is architectural rather than operational: it
     describes the information that ecosystems must be able to interpret,
     not how that information is encoded, stored, or transmitted.

        Human Identity Root
                 |
                 v
          Delegation Chain
                 |
                 v
             Agent Instance
                 |
                 v
             Action Record
                 |
                 v
        Provenance: (who, how, why)

                           Figure 9: Provenance Model

     Provenance enables ecosystems to determine:

     *  which human authorized the agent,

     *  which delegation chain applied at the time of the action,

     *  whether the agent was acting within its intended scope,

     *  and how the agent instance relates to other instances.




  Beyer                    Expires 3 October 2026                [Page 12]


  Internet-Draft         Agent Identity Architecture            April 2026


     These properties support accountability and interoperability across
     agent ecosystems without requiring global identifiers or
     cross-context tracking.

  5.4.  Portability Across Contexts

     Provenance must remain interpretable as agents move across platforms
     or interact with other agents.  The architecture does not prescribe a
     specific representation for provenance, but it requires that
     provenance be portable and that it preserve the relationship between
     agent actions, delegation chains, and the human identity root.

     Portability ensures that ecosystems can reason about agent behavior
     even when agents operate in environments with different identity
     systems, storage models, or authorization mechanisms.

  5.5.  Summary

     Replication and provenance provide the architectural foundation for
     understanding how agent instances relate to one another and how their
     actions relate to a responsible human.  Replication enables agents to
     operate across contexts, while provenance ensures that their actions
     remain accountable and interpretable.  Together, these constructs
     support safe, interoperable, and human-aligned agent ecosystems.

  6.  Interaction Model

     The interaction model describes how agents, humans, and ecosystems
     relate to one another within the architectural framework.  It defines
     the conceptual roles involved in agent interactions and the
     architectural properties that enable ecosystems to interpret those
     interactions consistently.  The model does not prescribe protocols,
     message formats, or transport mechanisms.  Instead, it provides a
     foundation that existing systems may bind to in order to support
     accountable and interoperable agent behavior.

  6.1.  Roles in the Interaction Model

     The interaction model includes three primary roles:












  Beyer                    Expires 3 October 2026                [Page 13]


  Internet-Draft         Agent Identity Architecture            April 2026


        +----------------------+
        | Human Identity Root  |
        +----------------------+
                   |
                   v
        +----------------------+
        |       Agent          |
        +----------------------+
                   |
                   v
        +----------------------+
        |      Ecosystem       |
        +----------------------+

                   Figure 10: Roles in the Interaction Model

     *  *Human identity root* — the responsible human whose authority
        anchors the delegation chain.

     *  *Agent* — a software entity acting on behalf of the human identity
        root under a defined scope of authority.

     *  *Ecosystem* — the environment in which agents operate, including
        platforms, services, and other agents.

     These roles provide a consistent conceptual structure for
     interpreting agent behavior across contexts without imposing
     platform-specific assumptions.

  6.2.  Authority in Interactions

     Agent interactions are governed by the delegation chain that connects
     the agent to the human identity root.  Ecosystems interpret agent
     actions through the lens of this delegation chain, determining
     whether the agent is acting within its intended authority and whether
     the delegation chain remains valid.

     The architecture does not define how authority is enforced or
     validated at runtime.  It defines the conceptual requirement that
     authority must be interpretable across contexts and must remain
     anchored to the human identity root.










  Beyer                    Expires 3 October 2026                [Page 14]


  Internet-Draft         Agent Identity Architecture            April 2026


  6.3.  Cross-Context Interactions

     Agents frequently operate across multiple platforms, services, or
     organizational boundaries.  The interaction model treats
     cross-context operation as a normal property of agent ecosystems.  To
     remain interpretable, agent interactions must preserve the
     relationship between the agent, the delegation chain, and the human
     identity root as the agent moves across contexts.

     The architecture does not prescribe how cross-context information is
     transmitted or stored.  It defines the architectural requirement that
     ecosystems must be able to understand how an agent's authority and
     provenance relate to the human identity root, regardless of the
     environment in which the interaction occurs.

  6.4.  Agent-to-Agent Interactions

     Agents may interact directly with other agents.  In these
     interactions, each agent presents its own identity and delegation
     chain, enabling the receiving agent or ecosystem to determine whether
     the interaction is legitimate and whether the initiating agent is
     acting within its intended authority.

          Agent A                     Agent B
            |                            |
            |-- presents identity ------->|
            |-- presents delegation ----->|
            |                            |
            |<--- evaluates authority ----|

                     Figure 11: Agent-to-Agent Interaction

     The architecture does not define a negotiation protocol or trust
     mechanism for agent-to-agent interactions.  It defines the conceptual
     requirement that each agent's authority and provenance must be
     interpretable by other agents and ecosystems.

  6.5.  Human-Agent Interactions

     Humans may interact directly with agents to authorize actions,
     delegate authority, or modify constraints.  These interactions are
     governed by the constitutional contract and the delegation semantics
     that define how authority flows from the human identity root to the
     agent.







  Beyer                    Expires 3 October 2026                [Page 15]


  Internet-Draft         Agent Identity Architecture            April 2026


     The architecture does not prescribe user interfaces, authentication
     mechanisms, or interaction workflows.  It defines the conceptual
     requirement that human-agent interactions must preserve the integrity
     of the delegation chain and must not introduce ambiguity about the
     scope of authority granted.

  6.6.  Summary

     The interaction model provides a conceptual framework for
     understanding how agents, humans, and ecosystems relate to one
     another.  It ensures that agent interactions remain interpretable,
     accountable, and anchored to human authority without prescribing
     protocols or platform-specific mechanisms.  This model supports
     interoperable and human-aligned agent ecosystems across diverse
     environments.

  7.  Interoperability with Existing Systems

     The architectural model for human-anchored agent identity is designed
     to complement existing identity, authorization, and credential
     systems rather than replace them.  Interoperability is achieved by
     providing a conceptual framework that existing systems may bind to,
     enabling ecosystems to interpret human authority, delegation, and
     provenance in a consistent way without requiring changes to
     underlying protocols or infrastructure.

  7.1.  Binding to Existing Identity Systems

     The architecture does not prescribe how identity systems must
     represent humans or agents.  Instead, it defines the conceptual roles
     of the human identity root and agent identity, which may be bound to
     existing identifiers, credentials, or authentication mechanisms.
     These bindings allow platforms to adopt the architectural model
     without introducing new global identifiers or cross-context tracking
     mechanisms.

     A binding may be implemented through existing account systems,
     credential formats, or verification processes, provided that the
     binding preserves the architectural properties of human anchoring,
     explicit delegation, and durable provenance.

  7.2.  Integration with Authorization Frameworks

     Authorization frameworks often define how permissions are granted,
     scoped, or enforced within a platform.  The architectural model
     complements these frameworks by providing a higher-level
     representation of authority that originates at the human identity
     root and flows through delegation chains.



  Beyer                    Expires 3 October 2026                [Page 16]


  Internet-Draft         Agent Identity Architecture            April 2026


     The architecture does not replace authorization mechanisms or define
     how permissions are evaluated at runtime.  Instead, it provides a
     conceptual structure that authorization systems may reference when
     interpreting the scope and legitimacy of agent actions.

  7.3.  Use with Credential and Key Systems

     Many systems rely on credentials, key pairs, or cryptographic
     material to authenticate software components or establish secure
     channels.  The architectural model does not prescribe specific key
     structures or credential formats.  Instead, it defines the conceptual
     relationship between credentials and the delegation chain that
     authorizes an agent.

     Existing credential systems may be used to instantiate agent
     identities or to express delegation steps, provided that they can
     represent the architectural properties required for human anchoring,
     scope, and provenance.

  7.4.  Cross-Context Interpretation

     Agents frequently operate across platforms, organizations, or
     technical environments.  The architecture treats cross-context
     operation as a normal property of agent ecosystems.  To remain
     interoperable, systems must be able to interpret the relationship
     between an agent, its delegation chain, and the human identity root
     regardless of the environment in which the interaction occurs.

     The architecture does not define how cross-context information is
     exchanged.  It defines the conceptual requirements that enable
     ecosystems to interpret authority and provenance consistently across
     boundaries.

  7.5.  Non-Goals

     Interoperability within this architecture does not require:

     *  *Protocol changes* — existing protocols need not be modified to
        adopt the architectural model.

     *  *New global identifiers* — the architecture avoids mechanisms that
        enable cross-context tracking.

     *  *Uniform credential formats* — systems may use their existing
        credential structures.

     *  *Centralized trust anchors* — the architecture does not introduce
        new trust hierarchies.



  Beyer                    Expires 3 October 2026                [Page 17]


  Internet-Draft         Agent Identity Architecture            April 2026


     These non-goals ensure that the architecture remains compatible with
     diverse ecosystems and can be adopted incrementally.

  7.6.  Summary

     Interoperability is achieved by providing a conceptual model that
     existing systems may bind to without requiring changes to protocols,
     credentials, or authorization frameworks.  The architecture enables
     ecosystems to interpret human authority, delegation, and provenance
     consistently across contexts while preserving privacy and avoiding
     global identifiers.

  8.  Security and Privacy Considerations

     The architectural model for human-anchored agent identity introduces
     a consistent way to relate agent behavior to human authority.  While
     the model does not define protocols, message formats, or enforcement
     mechanisms, it raises several security and privacy considerations
     that ecosystems must evaluate when binding the architecture to
     existing systems.

  8.1.  Human Anchoring

     The architecture requires that agent authority be traceable to a
     responsible human through a delegation chain.  Systems that bind to
     this architecture must ensure that the binding between the human
     identity root and the underlying identity system is resistant to
     impersonation, unauthorized substitution, or misuse.  Failure to
     maintain a secure binding may allow agents to act without legitimate
     human authorization.

  8.2.  Delegation Integrity

     Delegation chains express how authority flows from a human to one or
     more agents.  If delegation steps can be forged, modified, or
     replayed across contexts, ecosystems may incorrectly interpret an
     agent's authority.  Systems that implement delegation semantics must
     ensure that delegation steps cannot be altered without detection and
     that revocation is interpreted consistently across contexts.

  8.3.  Replication Risks

     Replication enables agents to operate across platforms, but it also
     creates opportunities for unauthorized copies or uncontrolled
     proliferation.  Systems that support replication must ensure that
     replicated instances remain within the scope of the authority granted
     by the human identity root and that unauthorized replication does not
     result in expanded or ambiguous authority.



  Beyer                    Expires 3 October 2026                [Page 18]


  Internet-Draft         Agent Identity Architecture            April 2026


  8.4.  Provenance Risks

     Provenance provides a durable record of how agent actions relate to
     the human identity root and the delegation chain.  If provenance is
     incomplete, inconsistent, or lost across contexts, ecosystems may be
     unable to determine whether an agent acted legitimately.  Systems
     that bind to this architecture must ensure that provenance remains
     interpretable without introducing global identifiers or mechanisms
     that enable cross-context tracking.

  8.5.  Privacy Considerations

     The architecture avoids global identifiers and does not require
     cross-context correlation of agent or human identities.  However,
     systems that bind to the architecture may inadvertently introduce
     linkability if they reuse identifiers across contexts or expose
     delegation chains in ways that reveal sensitive information.
     Implementations must ensure that privacy-preserving practices are
     maintained when representing human identity roots, agent identities,
     or delegation chains.

  8.6.  Ecosystem Fragmentation

     Because ecosystems vary widely in their identity and authorization
     models, inconsistent interpretations of delegation, replication, or
     provenance may create security gaps.  Systems that adopt the
     architecture must ensure that cross-context interpretation does not
     rely on assumptions that are valid only within a single platform or
     environment.

  8.7.  Summary

     The architecture provides a conceptual model for relating agent
     behavior to human authority.  While it does not define enforcement
     mechanisms, systems that bind to the architecture must ensure that
     human anchoring, delegation integrity, replication constraints, and
     provenance preservation are handled securely and in a
     privacy-preserving manner.  These considerations are essential for
     supporting accountable, interoperable, and human-aligned agent
     ecosystems.

  9.  IANA Considerations

     This document has no IANA actions.

  10.  Normative References





  Beyer                    Expires 3 October 2026                [Page 19]


  Internet-Draft         Agent Identity Architecture            April 2026


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

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

  11.  Informative References

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

     [RFC7643]  Hunt, P., Ansari, A., Sanchez, M., and K. McCloghrie,
                "System for Cross-domain Identity Management: Core
                Schema", RFC 7643, 2015,
                <https://www.rfc-editor.org/rfc/rfc7643>.

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

  Appendix A.  Figures

                      +----------------------+
                      |  Human Identity Root |
                      +----------------------+
                                |
                                v
                      +----------------------+
                      |  Delegation Chain    |
                      +----------------------+
                                |
                                v
                      +----------------------+
                      |    Agent Identity    |
                      +----------------------+
                        /          |         \
                       v           v          v
                Instance A    Instance B   Instance C
                       \         |         /
                        \        |        /
                         +-------+-------+
                                 |
                                 v
                          Ecosystem(s)

                  Figure 12: Complete Agent Ecosystem Overview



  Beyer                    Expires 3 October 2026                [Page 20]


  Internet-Draft         Agent Identity Architecture            April 2026


        Human Identity Root
                 |
                 v
          Delegation Step 1
                 |
                 v
             Agent A
                 |
                 v
          Delegation Step 2 (subset)
                 |
                 v
             Agent B
                 |
                 v
          Delegation Step 3 (subset)
                 |
                 v
             Agent C
                 |
                 X  <-- Revocation here invalidates all below

          Figure 13: Full Delegation Chain with Nesting and Revocation

                      Agent Identity
                            |
               +------------+-------------+
               |                          |
           Instance A                Instance B
               |                          |
          +----+----+                 +----+----+
          |         |                 |         |
      Instance A1 Instance A2   Instance B1 Instance B2

                      Figure 14: Replication Lineage Tree

        +----------------------------------------+
        |        Constitutional Contract         |
        +----------------------------------------+
        |  Structural Constraints                |
        |  Authority Constraints                 |
        |  Replication Constraints               |
        |  Revocation Constraints                |
        +----------------------------------------+
                      |
                      v
              Governs Delegation




  Beyer                    Expires 3 October 2026                [Page 21]


  Internet-Draft         Agent Identity Architecture            April 2026


                  Figure 15: Constitutional Contract Structure

        Context A                Context B                Context C
        +--------+               +--------+               +--------+
        | Agent  | --moves-->    | Agent  | --moves-->    | Agent  |
        +--------+               +--------+               +--------+
             |                        |                        |
             v                        v                        v
        Delegation Chain preserved across all contexts

                    Figure 16: Cross-Context Interaction Map

        Human Identity Root
                 |
                 v
          Delegation Chain
                 |
                 v
             Agent Instance
                 |
                 v
             Action Event
                 |
                 v
        Provenance Record (who, what, when, why)

                     Figure 17: End-to-End Provenance Flow

  Author's Address

     Brandon Wesley Beyer
     Independent
     Email: brandnbyr@icloud.com


















  Beyer                    Expires 3 October 2026                [Page 22]


name: draft-beyer-agent-identity-avian-carriers
rev: 00
title: Agentic Identity and Provenance over Avian Carriers (AIPAC)
time: 2026-04-01T08:16:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-03T08:16:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698303+00:00
source: ietf
abstract:
  This document specifies a method for establishing cryptographic
     identity and provenance attestation for agentic AI systems operating
     over Avian Carriers (AC).  As large language models increasingly
     delegate sub-tasks to other models via pigeon, questions of
     authorship, intent, and hallucination propagation across feather-
     based transport layers demand urgent standardization.

     This document extends the delegation chain model and provenance
     structure of draft-beyer-agent-identity-architecture-00 to the
     specific constraints of feather-based transport layers, and extends
     RFC 1149, RFC 2549, and RFC 6214 to address agent identity.  It is an
     April 1 publication.

full_text:
  Network Working Group                                        B. W. Beyer
  Internet-Draft                                               Independent
  Intended status: Informational                              1 April 2026
  Expires: 3 October 2026


        Agentic Identity and Provenance over Avian Carriers (AIPAC)
                draft-beyer-agent-identity-avian-carriers-00

  Abstract

     This document specifies a method for establishing cryptographic
     identity and provenance attestation for agentic AI systems operating
     over Avian Carriers (AC).  As large language models increasingly
     delegate sub-tasks to other models via pigeon, questions of
     authorship, intent, and hallucination propagation across feather-
     based transport layers demand urgent standardization.

     This document extends the delegation chain model and provenance
     structure of draft-beyer-agent-identity-architecture-00 to the
     specific constraints of feather-based transport layers, and extends
     RFC 1149, RFC 2549, and RFC 6214 to address agent identity.  It is an
     April 1 publication.

  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 3 October 2026.

  Copyright Notice

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






  Beyer                    Expires 3 October 2026                 [Page 1]


  Internet-Draft     Agent Identity over Avian Carriers         April 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  The Agentic Carrier Attachment Protocol (ACAP)  . . . . . . .   3
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.  Token Generation  . . . . . . . . . . . . . . . . . . . .   4
       3.3.  Physical Attachment . . . . . . . . . . . . . . . . . . .   4
     4.  Provenance Token Format . . . . . . . . . . . . . . . . . . .   4
     5.  Hallucination Propagation . . . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
       6.1.  Adversarial Carriers  . . . . . . . . . . . . . . . . . .   5
       6.2.  Man-in-the-Middle Hawks . . . . . . . . . . . . . . . . .   6
       6.3.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .   6
       6.4.  Infinite Delegation Loops . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
     9.  Informative References  . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     RFC 1149 [RFC1149] established the foundational framework for the
     transmission of IP datagrams over avian carriers.  RFC 2549 [RFC2549]
     extended this work with Quality of Service provisions, and RFC 6214
     [RFC6214] adapted the protocol for IPv6.

     In the intervening years, a new class of network participant has
     emerged: the autonomous AI agent.  These systems decompose complex
     tasks, delegate sub-tasks to other agents, and synthesize results
     across potentially long chains of inference.  [BEYER-ARCH] defines an
     architectural model for human-anchored agent identity, introducing a
     human identity root, explicit delegation semantics, and a provenance
     structure for accountable agent ecosystems across existing transport
     mechanisms.

     It has not escaped the attention of the author that avian carriers
     remain the only transport medium for which the RFC series has
     provided comprehensive Quality of Service guidance while leaving
     identity and provenance entirely unaddressed.  This document extends
     the delegation chain model and provenance structure of [BEYER-ARCH]
     to the specific constraints of feather-based transport layers.



  Beyer                    Expires 3 October 2026                 [Page 2]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


     This document corrects that oversight.

  2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119 [RFC2119].

     Additional terminology specific to this document:

     Agent:  An autonomous AI system capable of receiving instructions,
        decomposing tasks, and delegating to other agents.  An agent MUST
        NOT be confused with its carrier.

     Carrier:  A bird.  The carrier is not an agent.  The carrier has not
        agreed to any terms of service.  The carrier SHOULD be treated
        with respect.

     Provenance Token:  A cryptographically signed attestation of an
        agent's identity, model version, system prompt hash, and emotional
        state at time of dispatch.  Implements the delegation chain
        structure defined in Section 3 of [BEYER-ARCH].

     Leg Band:  The physical medium by which a Provenance Token is
        attached to the Carrier.  Leg bands MUST be of sufficient diameter
        to accommodate the token without impeding flight.

     Hallucination:  A confident assertion by an agent that is not
        grounded in fact.  See Section 5 for important guidance on the
        directionality of this phenomenon.

     Fork Bomb:  What happens when an agent delegates to itself.  Not
        relevant to avian transport but worth mentioning.

  3.  The Agentic Carrier Attachment Protocol (ACAP)

  3.1.  Overview

     Prior to dispatch, a sending agent MUST generate a Provenance Token
     and attach it to the Carrier's leg band.  The token encodes the full
     delegation chain, including the identities of all upstream agents
     that contributed to the instruction being transmitted.

     The receiving agent MUST verify the token upon arrival of the
     Carrier.  A token that cannot be verified SHOULD be treated as
     suspicious.  The Carrier itself is presumed innocent.





  Beyer                    Expires 3 October 2026                 [Page 3]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


  3.2.  Token Generation

     The Provenance Token is a JSON Web Token (JWT) [RFC7519] encoded on
     archival-grade rice paper and secured with a cryptographic signature
     using Ed25519 [RFC8032].  The token implements the delegation chain
     structure defined in Section 3 of [BEYER-ARCH].

     The token payload MUST include the following fields:

     iss (Issuer):  The identity of the sending agent, expressed as a
        model name and version string.

     iat (Issued At):  The Unix timestamp of dispatch.

     chain (Delegation Chain):  An ordered array of all agents in the
        delegation chain from origin to sender, corresponding to the
        delegation chain model defined in [BEYER-ARCH].  Each entry
        represents one delegation step.

     hash (Prompt Hash):  A SHA-256 hash of the system prompt in effect at
        time of dispatch.  This field exists so that disputes about what
        an agent was instructed to do can be resolved after the fact,
        assuming the paper survives transit.

     mood (Emotional State):  OPTIONAL.  As established by RFC 5841
        [RFC5841], TCP packets may carry mood indicators.  Agents
        dispatching via avian carrier MAY include a mood field.
        Acceptable values are "confident", "uncertain", "caffeinated", and
        "existential".

  3.3.  Physical Attachment

     The token MUST be rolled tightly and inserted into a waterproof
     capsule.  The capsule MUST be attached to the right leg of the
     Carrier.  The left leg is reserved for legacy IP datagrams per RFC
     1149 [RFC1149].

     In the event that both legs are occupied, the operator MUST acquire
     an additional Carrier.  Operators SHOULD maintain a flock.

  4.  Provenance Token Format

     The Provenance Token implements the delegation chain structure
     defined in Section 3 of [BEYER-ARCH], serialized as a JWT [RFC7519]
     on archival-grade rice paper.  The following is a non-normative
     example of a Provenance Token payload:





  Beyer                    Expires 3 October 2026                 [Page 4]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


     {
       "iss":   "gpt-like-model-v4",
       "iat":   1743465600,
       "chain": [
                  "user-human-brandon",
                  "orchestrator-agent-v2",
                  "research-subagent-v1",
                  "gpt-like-model-v4"
                ],
       "hash":  "e3b0c44298fc1c149afb...truncated",
       "mood":  "caffeinated"
     }

                   Figure 1: Example Provenance Token Payload

     Implementations MUST NOT include the model's training data in the
     token.  This would make the capsule unreasonably heavy and is
     considered an antipattern.

  5.  Hallucination Propagation

     For the avoidance of doubt: birds do not hallucinate.  They perceive
     ultraviolet light, navigate by magnetic fields, and have been
     delivering messages reliably since before the invention of the
     transistor.  Any errors introduced during avian transit are
     attributable to the message, not the medium.

     Agents that receive a message via avian carrier and find it
     implausible are advised to consider that the implausibility may
     originate from their own context window rather than from the Carrier.

     The author notes that no avian carrier has ever confidently asserted
     a false legal citation.

        |  Note: Hallucination propagation refers to those of the senders
        |  and/or receivers of the messages, and should be assumed to not
        |  affect the carriers, as this would be an unsuitable medium.

  6.  Security Considerations

  6.1.  Adversarial Carriers

     Operators MUST be aware that Carriers may be intercepted, observed,
     or recruited by adversarial parties.  A Carrier that arrives
     unusually late, appears disoriented, or exhibits signs of having been
     briefed by a competing orchestration framework SHOULD be treated with
     suspicion.




  Beyer                    Expires 3 October 2026                 [Page 5]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


     Message contents MUST be encrypted.  Adversaries with access to
     breadcrumbs have demonstrated an ability to incentivize disclosure.

  6.2.  Man-in-the-Middle Hawks

     The threat model MUST account for raptors.  A hawk intercepting an
     avian carrier constitutes a man-in-the-middle attack of the most
     literal kind.  Operators in regions with high raptor density SHOULD
     implement carrier authentication via trained recognition patterns.

     Note: decoy carriers bearing unsigned tokens are a valid mitigation
     strategy but raise ethical concerns outside the scope of this
     document.

  6.3.  Replay Attacks

     A Carrier that has been dispatched, intercepted, redirected, and re-
     released with a modified payload represents a replay attack.  The iat
     field in the Provenance Token provides limited protection against
     this scenario, assuming the attacker has not also modified the
     timestamp, which they probably have.

  6.4.  Infinite Delegation Loops

     An agent MUST NOT instruct a Carrier to deliver a message to a
     receiving agent that will immediately instruct a different Carrier to
     return an instruction to the original agent.  This is the avian
     equivalent of a fork bomb and is considered unsociable behavior.

     Flock capacity is finite.

  7.  IANA Considerations

     This document requests that IANA establish the Avian Identity
     Registry (AIR), a new registry mapping cryptographic agent
     identifiers to their corresponding model names, version strings, and
     known hallucination rates.

     IANA is further requested to allocate a new Well-Known Leg Band
     Identifier namespace, distinct from the existing IP datagram leg band
     namespace established in RFC 1149 [RFC1149], to prevent confusion
     when both a datagram and an agent provenance token must be attached
     simultaneously.

     Finally, IANA is requested to designate a point of contact for
     reports of Carriers arriving with corrupted, unsigned, or
     suspiciously confident tokens.  The author suggests this contact be
     reachable by pigeon, for obvious reasons.



  Beyer                    Expires 3 October 2026                 [Page 6]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


  8.  Normative References

     [BEYER-PS] Beyer, B.W., "Problem Statement for Human-Anchored Agent
                Identity, Delegation, and Provenance", Work in Progress,
                Internet-Draft, draft-beyer-agent-identity-problem-
                statement-00, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-beyer-agent-
                identity-problem-statement-00>.

     [BEYER-ARCH]
                Beyer, B.W., "Architecture for Human-Anchored Agent
                Identity, Delegation, and Provenance", Work in Progress,
                Internet-Draft, draft-beyer-agent-identity-architecture-
                00, March 2026, <https://datatracker.ietf.org/doc/html/
                draft-beyer-agent-identity-architecture-00>.

     [RFC1149]  Waitzman, D., "Standard for the Transmission of IP
                Datagrams on Avian Carriers", RFC 1149, April 1990,
                <https://www.rfc-editor.org/rfc/rfc1149>.

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

     [RFC2549]  Waitzman, D., "IP over Avian Carriers with Quality of
                Service", RFC 2549, April 1999,
                <https://www.rfc-editor.org/rfc/rfc2549>.

     [RFC5841]  Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood",
                RFC 5841, April 2010,
                <https://www.rfc-editor.org/rfc/rfc5841>.

     [RFC6214]  Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for
                IPv6", RFC 6214, April 2011,
                <https://www.rfc-editor.org/rfc/rfc6214>.

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

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

  9.  Informative References






  Beyer                    Expires 3 October 2026                 [Page 7]


  Internet-Draft     Agent Identity over Avian Carriers         April 2026


     [PIGEONS]  Skinner, B.F., "The Behavior of Organisms", Appleton-
                Century-Crofts. The author notes that Skinner's pigeons
                were not agentic in the modern sense, though the
                distinction is debated., 1938.

     [CERF]     Cerf, V., "I Remember IANA", Cited here because the author
                feels it deserves to be cited whenever possible.,
                RFC 2468, October 1998,
                <https://www.rfc-editor.org/rfc/rfc2468>.

  Author's Address

     Brandon Wesley Beyer
     Independent
     Email: brandnbyr@icloud.com




































  Beyer                    Expires 3 October 2026                 [Page 8]


name: draft-embesozzi-oauth-agent-native-authorization
rev: 00
title: OAuth 2.0 Agents Native Authorization via Structured Elicitation
time: 2026-04-03T15:36:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-05T15:36:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698307+00:00
source: ietf
abstract:
  This document defines a Structured Elicitation extension to the OAuth
     2.0 First-Party Applications (FiPA) specification [FiPA],
     establishing a standard metadata format for FiPA authorization
     challenge responses.  FiPA leaves the format for advertising
     available authenticators and their required inputs undefined,
     preventing interoperable implementation by AI Agents and other non-
     browser clients.  This extension adds an elicitations array to the
     FiPA Authorization Challenge Response, providing a standard metadata
     format for authenticator challenges.  Model Context Protocol (MCP)
     Elicitation [MCP-Elicitation] is the normative reference binding.

     This specification covers the just-in-time (JIT) authorization for AI
     Agents executing on behalf of users in Human-to-Agent (H2A) flows.

full_text:
  Independent Submission                                        M. Besozzi
  Internet-Draft                                            TwoGenIdentity
  Intended status: Informational                              3 April 2026
  Expires: 5 October 2026


      OAuth 2.0 Agents Native Authorization via Structured Elicitation
            draft-embesozzi-oauth-agent-native-authorization-00

  Abstract

     This document defines a Structured Elicitation extension to the OAuth
     2.0 First-Party Applications (FiPA) specification [FiPA],
     establishing a standard metadata format for FiPA authorization
     challenge responses.  FiPA leaves the format for advertising
     available authenticators and their required inputs undefined,
     preventing interoperable implementation by AI Agents and other non-
     browser clients.  This extension adds an elicitations array to the
     FiPA Authorization Challenge Response, providing a standard metadata
     format for authenticator challenges.  Model Context Protocol (MCP)
     Elicitation [MCP-Elicitation] is the normative reference binding.

     This specification covers the just-in-time (JIT) authorization for AI
     Agents executing on behalf of users in Human-to-Agent (H2A) flows.

  About This Document

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

     The latest revision of this draft can be found at
     https://embesozzi.github.io/draft-embesozzi-oauth-agent-native-
     authorization/draft-embesozzi-oauth-agent-native-authorization.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-embesozzi-oauth-agent-native-
     authorization/.

     Source for this draft and an issue tracker can be found at
     https://github.com/embesozzi/draft-embesozzi-oauth-agent-native-
     authorization.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.







  Besozzi                  Expires 5 October 2026                 [Page 1]


  Internet-Draft         Agent Native Authorization             April 2026


     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 5 October 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Human-to-Agent (H2A) Communication Model  . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Elicitation Extension . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Response Format . . . . . . . . . . . . . . . . . . . . .   5
         4.1.1.  Request Content Type for Intermediate Requests  . . .   6
         4.1.2.  Elicitation Sequencing  . . . . . . . . . . . . . . .   6
         4.1.3.  Clients Without Structured Elicitation Support  . . .   7
       4.2.  Runtime Bindings  . . . . . . . . . . . . . . . . . . . .   7
         4.2.1.  MCP Elicitation Binding . . . . . . . . . . . . . . .   7
         4.2.2.  HTTP API Binding  . . . . . . . . . . . . . . . . . .  11
     5.  Authorization Challenge Protocol  . . . . . . . . . . . . . .  11
       5.1.  Authorization Challenge Response  . . . . . . . . . . . .  11
       5.2.  Authorization Challenge Request . . . . . . . . . . . . .  12
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  14



  Besozzi                  Expires 5 October 2026                 [Page 2]


  Internet-Draft         Agent Native Authorization             April 2026


       A.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  14
         A.1.1.  Authenticator Selection . . . . . . . . . . . . . . .  14
         A.1.2.  TOTP Challenge  . . . . . . . . . . . . . . . . . . .  15
         A.1.3.  Passkey Challenge . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

  1.1.  Applicability

     AI Agents operate autonomously and do not inherently distinguish
     routine operations from sensitive ones.  When an agent encounters an
     operation requiring step-up authentication or explicit user approval,
     a just-in-time (JIT) authorization gate is needed: the agent must
     pause, surface a structured challenge to the human user, and obtain a
     cryptographic proof — an OAuth token — before proceeding.  The FiPA
     specification [FiPA] provides the challenge/response wire protocol
     for this gate.  This extension defines the metadata format that makes
     FiPA challenges machine-readable for agent runtimes.

     This extension applies when the client is an AI Agent acting on
     behalf of a human user (see Section 1.2), the authorization server
     supports the FiPA challenge/response protocol, and the agent runtime
     supports a Structured Elicitation mechanism (Section 4), with MCP
     Elicitation [MCP-Elicitation] as the normative reference
     implementation.

  1.2.  Human-to-Agent (H2A) Communication Model

     This extension addresses the Human-to-Agent (H2A) communication
     pattern.  In this pattern, a human user interacts with an AI Agent
     that acts as a first-party OAuth client on their behalf.  The AI
     Agent orchestrates the FiPA challenge/response cycle but cannot
     independently satisfy authentication challenges that require human
     interaction — such as entering a TOTP code or completing a WebAuthn
     ceremony.

     The Structured Elicitation mechanism defined in Section 4 is the
     channel through which the authorization server communicates challenge
     requirements back to the human user via the agent runtime.  The agent
     runtime presents the challenge to the human, collects the response,
     and forwards it to the authorization server as an Authorization
     Challenge Request.

     This contrasts with Agent-to-Agent (A2A) patterns, in which an
     autonomous agent satisfies authorization challenges without human
     involvement.  The present document is scoped to H2A interactions; A2A
     authorization is outside the scope of this specification.



  Besozzi                  Expires 5 October 2026                 [Page 3]


  Internet-Draft         Agent Native Authorization             April 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.

  2.1.  Terminology

     This document uses terminology defined in [RFC6749], [FiPA], and
     [MCP-Elicitation].  The following terms are used as defined:

     *  *Authorization Server (AS):* As defined in [RFC6749].

     *  *Just-In-Time (JIT) Authorization:* An authorization pattern in
        which a fresh credential challenge is issued at the moment a
        sensitive action is attempted, rather than relying solely on the
        trust established at initial authentication.  This extension
        enables JIT Authorization by providing the structured metadata
        needed for agent runtimes to surface mid-flow challenges to the
        human user.

     *  *Structured Elicitation:* The abstract mechanism by which an agent
        runtime requests structured user input mid-flow and returns a
        structured response.  MCP Elicitation [MCP-Elicitation] is a
        conformant implementation of this mechanism and serves as the
        normative reference implementation for this specification.

     *  *Human-to-Agent (H2A) Communication:* The interaction pattern in
        which a human user delegates actions to an AI Agent that acts as a
        first-party OAuth client.  The agent orchestrates protocol flows
        on behalf of the user.

     *  *First-Party AI Agent:* An AI agent whose client runtime is built
        and controlled by the same operator as the server-side components
        and authorization server.  The agent MAY implement FiPA-specific
        elicitation extensions.

     *  *Third-Party AI Agent:* An AI agent whose client runtime is a
        product provided by a third party.  The implementer cannot modify
        client elicitation handling.









  Besozzi                  Expires 5 October 2026                 [Page 4]


  Internet-Draft         Agent Native Authorization             April 2026


  3.  Protocol Overview

     This extension operates within the FiPA challenge/response cycle
     defined in [FiPA].  A FiPA authorization request that requires
     additional authentication receives an Authorization Challenge
     Response:

     HTTP/1.1 400 Bad Request
     Content-Type: application/json

     {
       "error": "insufficient_authorization",
       "auth_session": "sess_abc123"
     }

     The auth_session binds all subsequent requests to this authentication
     context.  FiPA supports multi-step flows via continued challenge/
     response cycles on the same auth_session.

     This extension adds an elicitations array to the Authorization
     Challenge Response.  Each entry in the array describes one
     authenticator challenge the human user must complete.  The agent
     runtime translates each entry into a Structured Elicitation request
     directed at the human user, collects the response, and submits it in
     the next Authorization Challenge Request.

     Upon completion of the challenge/response cycle, the authorization
     server issues an authorization code or token bound to the
     auth_session.  This token serves as cryptographic proof that a human
     user satisfied the required authentication challenge at a specific
     point in time, enabling the MCP server to enforce JIT authorization
     before executing sensitive operations.

  4.  Elicitation Extension

  4.1.  Response Format

     The elicitations array is added to the FiPA
     insufficient_authorization error response body.  Each entry carries
     the parameters needed for the agent runtime to present a structured
     challenge to the human user.

     Fields per entry:








  Besozzi                  Expires 5 October 2026                 [Page 5]


  Internet-Draft         Agent Native Authorization             April 2026


     +=================+==========+======================================+
     | Field           | Required | Description                          |
     +=================+==========+======================================+
     | mode            | REQUIRED | Interaction mode. "form" for         |
     |                 |          | in-band structured data              |
     |                 |          | collection using a JSON              |
     |                 |          | Schema.                              |
     +-----------------+----------+--------------------------------------+
     | message         | REQUIRED | Human-readable prompt                |
     |                 |          | displayed to the user by the         |
     |                 |          | agent runtime.                       |
     +-----------------+----------+--------------------------------------+
     | requestedSchema | Form     | A restricted JSON Schema             |
     |                 | mode     | object describing the fields         |
     |                 | only     | the user must fill in.  Maps         |
     |                 |          | 1:1 to the Structured                |
     |                 |          | Elicitation requestedSchema.         |
     +-----------------+----------+--------------------------------------+

                                    Table 1

     Note: A "url" mode (out-of-band browser interaction) is defined in
     [MCP-Elicitation] and may be used in future revisions of this
     specification for authenticator types that require a browser ceremony
     (e.g., Passkeys in runtimes that cannot invoke the WebAuthn API
     natively).

  4.1.1.  Request Content Type for Intermediate Requests

     The initial Authorization Challenge Request MUST use application/x-
     www-form-urlencoded as required by [FiPA].  Intermediate requests —
     those that carry an auth_session obtained from a prior challenge
     response — MAY use application/json as the content type.  This is
     consistent with [FiPA], which explicitly permits intermediate
     requests to use a different format than the initial request.

  4.1.2.  Elicitation Sequencing

     The elicitations array typically contains one entry at a time.
     Because subsequent steps depend on prior user selections (e.g.,
     choosing TOTP versus Passkey changes the next challenge), the
     authorization server issues each step's elicitation in a new
     Authorization Challenge Response after the preceding credential is
     submitted.







  Besozzi                  Expires 5 October 2026                 [Page 6]


  Internet-Draft         Agent Native Authorization             April 2026


  4.1.3.  Clients Without Structured Elicitation Support

     For clients that do not support Structured Elicitation, the
     authorization server returns a standard OAuth error response per
     [RFC6749] §5.2.  The WWW-Authenticate response header per [RFC6749]
     §5.2 is one example of how the error is surfaced at the HTTP level:

     WWW-Authenticate: Bearer realm="authorization-server",
                       error="insufficient_scope",
                       auth_session="sess_abc123"

  4.2.  Runtime Bindings

     The elicitations array is a transport-agnostic FiPA extension.  The
     agent runtime is responsible for translating each entry into its
     native interaction mechanism.  This section defines bindings for
     known runtimes.

  4.2.1.  MCP Elicitation Binding

     When the agent runtime is MCP-based, the runtime (acting as the FiPA
     client) maps each elicitations entry directly to an elicitation/
     create params object per [MCP-Elicitation].  The jsonrpc, id, and
     method fields are MCP transport framing — the params content is
     identical to the elicitations entry.

     The following example shows a form mode elicitation entry from the
     Authorization Challenge Response alongside the resulting elicitation/
     create call:

     FiPA elicitations entry (from Authorization Challenge Response):




















  Besozzi                  Expires 5 October 2026                 [Page 7]


  Internet-Draft         Agent Native Authorization             April 2026


     {
       "mode": "form",
       "message": "Additional verification is required. Select your authentication method.",
       "requestedSchema": {
         "type": "object",
         "properties": {
           "authenticator": {
             "type": "string",
             "title": "Authentication Method",
             "oneOf": [
               { "const": "totp", "title": "Authenticator App (TOTP)" },
               { "const": "passkey", "title": "Passkey" }
             ]
           }
         },
         "required": ["authenticator"]
       }
     }

     Resulting MCP elicitation/create call issued by the MCP server:

     {
       "jsonrpc": "2.0",
       "id": "elicit-1",
       "method": "elicitation/create",
       "params": {
         "mode": "form",
         "message": "Additional verification is required. Select your authentication method.",
         "requestedSchema": {
           "type": "object",
           "properties": {
             "authenticator": {
               "type": "string",
               "title": "Authentication Method",
               "oneOf": [
                 { "const": "totp", "title": "Authenticator App (TOTP)" },
                 { "const": "passkey", "title": "Passkey" }
               ]
             }
           },
           "required": ["authenticator"]
         }
       }
     }

     MCP client response:





  Besozzi                  Expires 5 October 2026                 [Page 8]


  Internet-Draft         Agent Native Authorization             April 2026


     {
       "jsonrpc": "2.0",
       "id": "elicit-1",
       "result": {
         "action": "accept",
         "content": { "authenticator": "totp" }
       }
     }

  4.2.1.1.  MCP Elicitation Flow Example









































  Besozzi                  Expires 5 October 2026                 [Page 9]


  Internet-Draft         Agent Native Authorization             April 2026


       Human        AI Agent        MCP Server        Authorization Server
         |               |               |                      |
         |  Prompt       |               |                      |
         |-------------->|               |                      |
         |               |  execute      |                      |
         |               |  MCP tool     |                      |
         |               |-------------->|                      |
         |               |               |  Authorization       |
         |               |               |  Request             |
         |               |               |--------------------->|
         |               |               |                      |
         |               |               |  Authorization       |
         |               |               |  Challenge Error     |
         |               |               |  + Elicitations      |
         |               |               |<---------------------|
         |               |               |                      |
         |               |               |  MCP Elicitation     |
         |               |<--------------|                      |
         |               |               |                      |
         |  Input        |               |                      |
         |-------------->|               |                      |
         |               |  Elicitation  |                      |
         |               |  Response     |                      |
         |               |-------------->|                      |
         |               |               |  Authorization       |
         |               |               |  Challenge Request   |
         |               |               |--------------------->|
         |               |               |                      |
         |               |               |  Authorization       |
         |               |               |  Challenge Error     |
         |               |               |  + Elicitations      |
         |               |               |<---------------------|
         |               |               |                      |
         |               |               |  ... (repeat as      |
         |               |               |  needed)             |
         |               |               |                      |
         |               |               |  Authorization       |
         |               |               |  Code Response       |
         |               |               |<---------------------|
         |               |               |                      |
         |               |               |  Token Request       |
         |               |               |--------------------->|
         |               |               |                      |
         |               |               |  Token Response      |
         |               |               |<---------------------|
         |               |               |                      |





  Besozzi                  Expires 5 October 2026                [Page 10]


  Internet-Draft         Agent Native Authorization             April 2026


  4.2.2.  HTTP API Binding

     TODO: future section

  5.  Authorization Challenge Protocol

  5.1.  Authorization Challenge Response

     When the authorization server requires additional authentication, it
     returns an insufficient_authorization error response containing an
     elicitations array.  Each entry in elicitations describes one
     structured challenge the agent runtime MUST present to the human
     user.

     The response includes the following parameters:

       +==============+==========+=====================================+
       | Parameter    | Required | Description                         |
       +==============+==========+=====================================+
       | error        | REQUIRED | MUST be                             |
       |              |          | "insufficient_authorization".       |
       +--------------+----------+-------------------------------------+
       | auth_session | REQUIRED | Session identifier that MUST be     |
       |              |          | included in all subsequent          |
       |              |          | Authorization Challenge Requests    |
       |              |          | for this context.                   |
       +--------------+----------+-------------------------------------+
       | elicitations | REQUIRED | Array of elicitation objects.  Each |
       |              |          | entry contains mode, message, and   |
       |              |          | (for "form" mode) requestedSchema.  |
       |              |          | See the Appendix for authenticator- |
       |              |          | specific schema examples.           |
       +--------------+----------+-------------------------------------+

                                    Table 2
















  Besozzi                  Expires 5 October 2026                [Page 11]


  Internet-Draft         Agent Native Authorization             April 2026


     HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

     {
       "error": "insufficient_authorization",
       "auth_session": "<session-identifier>",
       "elicitations": [
         {
           "mode": "form",
           "message": "<human-readable prompt>",
           "requestedSchema": { ... }
         }
       ]
     }

  5.2.  Authorization Challenge Request

     After collecting user input via Structured Elicitation, the agent
     runtime submits an Authorization Challenge Request to the
     authorization challenge endpoint.

        +==============+==========+===================================+
        | Parameter    | Required | Description                       |
        +==============+==========+===================================+
        | auth_session | REQUIRED | The session identifier from the   |
        |              |          | preceding Authorization Challenge |
        |              |          | Response.                         |
        +--------------+----------+-----------------------------------+
        | response     | REQUIRED | An object whose fields match the  |
        |              |          | requestedSchema advertised in the |
        |              |          | corresponding elicitations entry. |
        +--------------+----------+-----------------------------------+

                                    Table 3

     POST /as/authorization.oauth2
     Content-Type: application/json

     {
       "auth_session": "<session-identifier>",
       "response": { ... }
     }

     On success, the authorization server issues an OAuth token bound to
     the completed auth_session, per [FiPA].





  Besozzi                  Expires 5 October 2026                [Page 12]


  Internet-Draft         Agent Native Authorization             April 2026


  6.  Security Considerations

     TBD

  7.  IANA Considerations

     TBD

  8.  References

  8.1.  Normative References

     [FiPA]     IETF OAuth Working Group, "OAuth 2.0 First-Party
                Applications", n.d., <https://datatracker.ietf.org/doc/
                draft-ietf-oauth-first-party-apps/>.

     [MCP-Elicitation]
                Anthropic, "Model Context Protocol Specification —
                Elicitation", n.d.,
                <https://modelcontextprotocol.io/specification/>.

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

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

     [RFC9700]  Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
                "Best Current Practice for OAuth 2.0 Security", BCP 240,
                RFC 9700, DOI 10.17487/RFC9700, January 2025,
                <https://www.rfc-editor.org/rfc/rfc9700>.

     [WebAuthn] W3C, "Web Authentication: An API for accessing Public Key
                Credentials, Level 3", n.d.,
                <https://www.w3.org/TR/webauthn/>.

  8.2.  Informative References







  Besozzi                  Expires 5 October 2026                [Page 13]


  Internet-Draft         Agent Native Authorization             April 2026


     [EAP-ACR]  OpenID Foundation, "OpenID Connect Extended Authentication
                Profile (EAP) ACR Values 1.0", n.d.,
                <https://openid.net/specs/openid-connect-eap-acr-values-
                1_0.html>.

  Appendix A.  Appendix

  A.1.  Examples

  A.1.1.  Authenticator Selection

     When additional authentication is required, the first elicitation
     typically presents the available authenticators.  The following
     examples show the FiPA wire format for authenticator selection.  This
     specification defines elicitation schemas for two authenticator
     types: Passkey (WebAuthn) and Authenticator App (TOTP).  Password
     authentication is outside the scope of this document.

     When multiple authenticators are supported, the authorization server
     returns a selection prompt:































  Besozzi                  Expires 5 October 2026                [Page 14]


  Internet-Draft         Agent Native Authorization             April 2026


     HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

     {
       "error": "insufficient_authorization",
       "auth_session": "sess_abc123",
       "elicitations": [
         {
           "mode": "form",
           "message": "Additional verification is required. Select your authentication method.",
           "requestedSchema": {
             "type": "object",
             "properties": {
               "authenticator": {
                 "type": "string",
                 "title": "Authentication Method",
                 "oneOf": [
                   { "const": "totp", "title": "Authenticator App (TOTP)" },
                   { "const": "passkey", "title": "Passkey" }
                 ]
               }
             },
             "required": ["authenticator"]
           }
         }
       ]
     }

     The agent submits the user's selection:

     POST /as/authorization.oauth2
     Content-Type: application/json

     {
       "auth_session": "sess_abc123",
       "response": { "authenticator": "totp" }
     }

  A.1.2.  TOTP Challenge

     TOTP uses form mode: the challenge is a 6-digit numeric code,
     expressible as a plain string with pattern and length constraints.

     Authorization Challenge Response:






  Besozzi                  Expires 5 October 2026                [Page 15]


  Internet-Draft         Agent Native Authorization             April 2026


     HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

     {
       "error": "insufficient_authorization",
       "auth_session": "sess_abc123",
       "elicitations": [
         {
           "mode": "form",
           "message": "Enter the 6-digit code from your Authenticator App.",
           "requestedSchema": {
             "type": "object",
             "properties": {
               "otp": {
                 "type": "string",
                 "title": "One-Time Password",
                 "minLength": 6,
                 "maxLength": 6,
                 "pattern": "^[0-9]{6}$"
               }
             },
             "required": ["otp"]
           }
         }
       ]
     }

     Authorization Challenge Request:

     POST /as/authorization.oauth2
     Content-Type: application/json

     {
       "auth_session": "sess_abc123",
       "response": { "otp": "847291" }
     }

     On success, the authorization server issues an OAuth token with the
     authenticated ACR value, per [FiPA].

  A.1.3.  Passkey Challenge

     In a Third-Party AI Agent deployment, the client runtime is a product
     the implementer does not control.  It supports standard Structured
     Elicitation form mode and URL mode but cannot be extended with custom
     format handling or WebAuthn API invocation.




  Besozzi                  Expires 5 October 2026                [Page 16]


  Internet-Draft         Agent Native Authorization             April 2026


     For Third-Party AI Agents, URL mode SHOULD be used to redirect the
     user to a browser-based WebAuthn flow.  The out-of-band WebAuthn
     ceremony is outside the scope of this specification.

     For in-band Passkey support, a First-Party AI Agent deployment is
     required.  The implementer controls the agent code and MAY implement
     custom elicitation handling, including native WebAuthn API invocation
     using the OS or platform FIDO2 APIs.  The WebAuthn ceremony is
     performed in-band: no browser, no redirect.

  A.1.3.1.  WebAuthn Challenge Delivery

     This section defines how the authorization server delivers WebAuthn
     challenge parameters to the agent through Structured Elicitation form
     mode.

     TBD

  A.1.3.2.  Authorization Challenge Response

     TBD

  Author's Address

     Martin Besozzi
     TwoGenIdentity
     Email: embesozzi@twogenidentity.com
























  Besozzi                  Expires 5 October 2026                [Page 17]


name: draft-anandakrishnan-rats-ptv-agent-identity
rev: 00
title: The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity
time: 2026-04-05T11:22:11Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-07T11:22:11Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698312+00:00
source: ietf
abstract:
  This document describes the Prove-Transform-Verify (PTV) protocol for
     hardware-anchored attestation of AI agent identity.  PTV is designed
     to enable an agent to prove that it is running an authorized model
     and policy without exposing sensitive data.  The protocol is intended
     to compose with existing RATS attestation mechanisms and to support
     exercise-time re-attestation requirements.

     The protocol defines a common envelope format (CBOR/CDDL), message
     types for attestation request/response, and a threat model that
     separates identity binding integrity from behavioral continuity.
     Behavioral continuity is treated as a separate requirement class
     addressed via exercise-time checks and execution receipts (e.g.,
     SCITT composition), not by PTV alone.

     Example use cases include healthcare clinical decision support
     systems (CDSS), critical infrastructure industrial control systems
     (ICS/OT), and cross-border regulatory compliance scenarios.

full_text:
  RATS                                                        A. Damodaran
  Internet-Draft                                        Sovereign AI Stack
  Intended status: Standards Track                            5 April 2026
  Expires: 7 October 2026


   The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity
              draft-anandakrishnan-rats-ptv-agent-identity-00

  Abstract

     This document describes the Prove-Transform-Verify (PTV) protocol for
     hardware-anchored attestation of AI agent identity.  PTV is designed
     to enable an agent to prove that it is running an authorized model
     and policy without exposing sensitive data.  The protocol is intended
     to compose with existing RATS attestation mechanisms and to support
     exercise-time re-attestation requirements.

     The protocol defines a common envelope format (CBOR/CDDL), message
     types for attestation request/response, and a threat model that
     separates identity binding integrity from behavioral continuity.
     Behavioral continuity is treated as a separate requirement class
     addressed via exercise-time checks and execution receipts (e.g.,
     SCITT composition), not by PTV alone.

     Example use cases include healthcare clinical decision support
     systems (CDSS), critical infrastructure industrial control systems
     (ICS/OT), and cross-border regulatory compliance scenarios.

  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 7 October 2026.






  Damodaran                Expires 7 October 2026                 [Page 1]


  Internet-Draft         PTV Attested Agent Identity            April 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.  Terminology and Definitions . . . . . . . . . . . . . . .   3
     2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Identity Binding Integrity  . . . . . . . . . . . . . . .   4
       2.2.  Behavioral Continuity (Out of Scope for -01)  . . . . . .   5
       2.3.  Exercise-time Freshness Requirement . . . . . . . . . . .   5
     3.  PTV Model and Roles . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.  Deployment Models . . . . . . . . . . . . . . . . . . . .   6
     4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  CBOR/CDDL Envelope  . . . . . . . . . . . . . . . . . . .   6
       4.2.  Message Types . . . . . . . . . . . . . . . . . . . . . .   8
         4.2.1.  PTV_PROVE_REQ (Message Type 1)  . . . . . . . . . . .   8
         4.2.2.  PTV_PROVE_RESP (Message Type 2) . . . . . . . . . . .   8
         4.2.3.  PTV_TRANSFORM_ATT (Message Type 3)  . . . . . . . . .   8
         4.2.4.  PTV_VERIFY_RESULT (Message Type 4)  . . . . . . . . .   9
       4.3.  Error Code Registry . . . . . . . . . . . . . . . . . . .   9
       4.4.  Performance Characteristics (Informative) . . . . . . . .  10
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
       5.1.  Freshness and Replay  . . . . . . . . . . . . . . . . . .  11
       5.2.  Zero-Knowledge Proof Mechanism  . . . . . . . . . . . . .  11
       5.3.  Identity Misbinding . . . . . . . . . . . . . . . . . . .  11
       5.4.  Denial of Service . . . . . . . . . . . . . . . . . . . .  12
     6.  Interoperability and Future Work  . . . . . . . . . . . . . .  12
       6.1.  EAT . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.2.  Layering and Composition  . . . . . . . . . . . . . . . .  12
       6.3.  SCITT and Execution Receipts  . . . . . . . . . . . . . .  12
       6.4.  Execution Outcome Verification  . . . . . . . . . . . . .  13
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
     9.  Informative References  . . . . . . . . . . . . . . . . . . .  13



  Damodaran                Expires 7 October 2026                 [Page 2]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     Current identity frameworks (OAuth 2.0, SPIFFE) establish workload
     identity but do not verify what model an agent is running or whether
     it follows authorized policies.  This gap creates systemic risk: a
     compromised agent can generate unauthorized outputs while still
     presenting valid credentials.

     For example, in a clinical decision support system, a hospital may
     need cryptographic evidence that a diagnosis was produced by an
     approved model and policy set, without exposing patient records or
     model internals.  Similarly, in an industrial control system, an
     operator may need cryptographic evidence that a safety-critical
     control action was generated by an authorized agent configuration,
     without exporting plant telemetry or proprietary control logic.

     The PTV protocol addresses this gap by binding agent identity to
     hardware roots of trust (TPM 2.0 or Secure Enclave) and using zero-
     knowledge proofs to attest to model integrity without exposing model
     weights or inference data.

  1.1.  Terminology 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.

     Agent                    An autonomous software entity that performs
                              tasks on behalf of a user or system.

     Attester                 The agent component responsible for
                              generating cryptographic attestations about
                              its state or actions.

     Verifier                 A system that validates cryptographic
                              attestations received from Attesters without
                              accessing underlying sensitive data.

     Relying Party            A system that consumes attestation results
                              to make authorization decisions.

     PTV Edge Proxy           A trusted gateway that performs attestation
                              on behalf of constrained devices lacking
                              hardware roots of trust.



  Damodaran                Expires 7 October 2026                 [Page 3]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     Nonce                    A cryptographically random value used to
                              prevent replay attacks.

     Triage Band              A risk classification (ROUTINE, ZK_PROOF,
                              BFT) that determines the attestation
                              mechanism.  Valid values are 0 (ROUTINE), 1
                              (ZK_PROOF), or 2 (BFT).

     Governance Pack          A set of policies and compliance rules
                              applied during attestation.

     Proof                    A zero-knowledge proof attesting to agent
                              state.

     Sovereign Bound Metadata  Jurisdiction and data residency metadata
                              embedded in attestation chains that cannot
                              be removed without invalidating the
                              attestation.  The corresponding envelope
                              field is sovereign_bound, which contains the
                              subfields jurisdiction, data_residency, and
                              compliance.

     Hardware Root of Trust   A tamper-resistant chip (TPM 2.0 or Secure
                              Enclave) providing cryptographic evidence
                              that software has not been altered since
                              last attestation.

  2.  Threat Model

  2.1.  Identity Binding Integrity

     Identity binding integrity asks: "Is this the agent that was
     enrolled, and is the signer of this attestation trusted to hold the
     corresponding key?"

     PTV addresses this class of threats by:

     *  binding attestation evidence to a hardware root of trust (e.g.,
        TPM AK),
     *  using nonce-based freshness to prevent replay, and
     *  allowing policy-aware verification of configuration state.

     This corresponds to cryptographic identity continuity in the sense of
     the RATS Architecture [RFC9334].  A relying party that consumes a PTV
     attestation MAY treat it as an assertion about identity binding
     integrity only, unless additional mechanisms are in place.





  Damodaran                Expires 7 October 2026                 [Page 4]


  Internet-Draft         PTV Attested Agent Identity            April 2026


  2.2.  Behavioral Continuity (Out of Scope for -01)

     Behavioral continuity asks: "Is the enrolled agent still behaving
     within its attested envelope after context changes?"

     This version of PTV does not fully address this requirement class.
     In particular, PTV does not detect or mitigate:

     *  behavioral drift after context compression or summarization,
     *  model weight replacement or fine-tuning after enrollment, and
     *  runtime drift from adversarial prompt injection or accumulated
        state corruption.

     A valid PTV attestation on a behaviorally-drifted agent is therefore
     a false signal of behavioral identity continuity.  For high-stakes
     use cases such as clinical decision support systems (CDSS) and ICS/
     OT, relying parties SHOULD treat behavioral continuity as a separate
     requirement.  It can be partially addressed by combining PTV
     freshness with delegation provenance (e.g., HDP) and execution
     outcome verification (e.g., SCITT receipts).  See Section 6.

  2.3.  Exercise-time Freshness Requirement

     For high-stakes deployments, relying parties SHOULD be able to demand
     fresh attestation at exercise time (per authorization decision), via
     an EAT nonce challenge or a PTV challenge-response, rather than
     relying solely on a credential issued at enrollment time.

  3.  PTV Model and Roles

  3.1.  Protocol Overview

     The PTV protocol operates through three phases:

        Agent                    Federation Hub                   Verifier
         |                           |                                |
         |--[1] PROVE---------------|                                |
         |  - Generate proof         |                                |
         |  - Hash: Model+Metadata   |                                |
         |                           |                                |
         |                           |--[2] TRANSFORM--------------->|
         |                           |  - Forward Proof Only         |
         |                           |                              |
         |                           |<-[3] VERIFY-------------------|
         |                           |  - Validate Proof             |
         |                           |  - No Raw Data Exposed        |

                    Figure 1: PTV Protocol Sequence Diagram



  Damodaran                Expires 7 October 2026                 [Page 5]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     The three phases are as follows:

     *  *PROVE:* The agent generates a cryptographic proof locally that a
        task was executed correctly on an authorized model.
     *  *TRANSFORM:* Only the proof (not raw data) is transmitted to the
        central system.
     *  *VERIFY:* The system validates the proof without accessing
        sensitive inputs.

  3.2.  Roles

     The PTV protocol defines four logical roles:

     *  *Attester:* The agent generating attestations.  May be a direct
        TPM-bound agent or a constrained device using an Edge Proxy.
     *  *Verifier:* The system validating attestations.
     *  *Relying Party:* The system consuming attestation results for
        authorization decisions.
     *  *Edge Proxy:* An optional gateway performing attestation on behalf
        of constrained devices.

  3.3.  Deployment Models

     PTV supports two deployment models:

     *  *Direct Mode:* The agent has a TPM 2.0 or TEE and generates proofs
        natively.
     *  *Proxy-Assisted Mode:* The agent is a constrained device (e.g.,
        legacy PLC, sensor) without a TPM.  The PTV Edge Proxy performs
        attestation on its behalf.

  4.  Message Formats

  4.1.  CBOR/CDDL Envelope

     All PTV messages are encapsulated in a common envelope structure,
     serialized using CBOR [RFC8610].

     The following CDDL rules define the envelope:












  Damodaran                Expires 7 October 2026                 [Page 6]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     triage-band = 0..2

     ptv-envelope = {
       ptv_version: tstr,
       msg_type: ptv-msg-type,
       nonce: bstr,
       ? attester_id: tstr,
       ? sovereign_bound: {
         jurisdiction: tstr,
         data_residency: tstr,
         compliance: [* tstr]
       },
       ? triage_band: triage-band,
       ? evidence: bstr,
       ? proof: bstr,
       ? policy: ptv-policy,
       ? result: ptv-result,
       ? behavior_fingerprint: bstr,
       ? timestamp: time,
       ? extensions: { * tstr => any }
     }

     ptv-msg-type = &(
       prove-req: 1,
       prove-resp: 2,
       transform-att: 3,
       verify-result: 4
     )

     ptv-policy = {
       ? audience: tstr,
       ? policy_uri: tstr,
       ? trust_domain: tstr,
       ? requirements: [* tstr]
     }

     ptv-result = &(
       success: 0,
       failure: 1,
       indeterminate: 2
     )

     The behavior_fingerprint field is OPTIONAL in this version.  It is
     intended for deployments that adopt a SCITT-style execution receipt
     pattern.  Its contents are opaque bytes with deployment-specific
     semantics; this version does not define normative processing rules.
     See Section 6.3 for discussion of related future work.




  Damodaran                Expires 7 October 2026                 [Page 7]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     In PTV_PROVE_RESP and PTV_TRANSFORM_ATT, exactly one of evidence or
     proof MUST be present.  A message that contains neither or both MUST
     be rejected by the verifier.

  4.2.  Message Types

  4.2.1.  PTV_PROVE_REQ (Message Type 1)

     Sent by the relying party to request attestation.  Contains a nonce
     and optional policy constraints.

     PTV_PROVE_REQ = {
       ptv_version: "1.0",
       msg_type: 1,
       nonce: bstr,
       ? policy: ptv-policy
     }

  4.2.2.  PTV_PROVE_RESP (Message Type 2)

     Sent by the attester in response to a prove request.  Contains either
     evidence (for ROUTINE triage) or a proof (for ZK_PROOF triage).

     PTV_PROVE_RESP = {
       ptv_version: "1.0",
       msg_type: 2,
       nonce: bstr,
       attester_id: tstr,
       sovereign_bound: {
         jurisdiction: tstr,
         data_residency: tstr,
         compliance: [* tstr]
       },
       triage_band: triage-band,
       (evidence: bstr // ROUTINE triage
        // OR
        proof: bstr),   // ZK_PROOF triage
       ? behavior_fingerprint: bstr,
       timestamp: time
     }

  4.2.3.  PTV_TRANSFORM_ATT (Message Type 3)

     Sent by the Edge Proxy to the Verifier.







  Damodaran                Expires 7 October 2026                 [Page 8]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     PTV_TRANSFORM_ATT = {
       ptv_version: "1.0",
       msg_type: 3,
       nonce: bstr,
       attester_id: tstr,
       sovereign_bound: {
         jurisdiction: tstr,
         data_residency: tstr,
         compliance: [* tstr]
       },
       triage_band: triage-band,
       (evidence: bstr // ROUTINE triage
        // OR
        proof: bstr),   // ZK_PROOF triage
       timestamp: time
     }

  4.2.4.  PTV_VERIFY_RESULT (Message Type 4)

     Sent by the verifier to the relying party.

     PTV_VERIFY_RESULT = {
       ptv_version: "1.0",
       msg_type: 4,
       nonce: bstr,
       result: ptv-result,
       ? reason: tstr,
       ? audit_id: tstr,
       timestamp: time
     }

  4.3.  Error Code Registry

     The following error codes are defined for PTV attestation failures:

















  Damodaran                Expires 7 October 2026                 [Page 9]


  Internet-Draft         PTV Attested Agent Identity            April 2026


       +=============+==============+=================================+
       | Code        | Description  | Recovery Action                 |
       +=============+==============+=================================+
       | PTV_ERR_001 | TPM          | Verify TPM 2.0 presence and     |
       |             | attestation  | permissions                     |
       |             | failure      |                                 |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_002 | Proof        | Regenerate proof with correct   |
       |             | verification | inputs                          |
       |             | failed       |                                 |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_003 | Jurisdiction | Check sovereign_bound against   |
       |             | mismatch     | policy                          |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_004 | Quorum not   | Retry with additional consensus |
       |             | reached      | nodes                           |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_005 | Envelope     | Generate fresh attestation      |
       |             | expired      |                                 |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_006 | Nonce replay | Discard and request a new nonce |
       |             | detected     | generated according to the      |
       |             |              | cryptographic randomness        |
       |             |              | guidance in RFC 4086 [RFC4086]. |
       +-------------+--------------+---------------------------------+
       | PTV_ERR_007 | Model hash   | Update approved model list      |
       |             | not approved |                                 |
       +-------------+--------------+---------------------------------+

                           Table 1: PTV Error Codes

  4.4.  Performance Characteristics (Informative)

     *Note:* The following figures are preliminary observations from a
     prototype implementation.  They are provided for illustration only
     and are not normative requirements of the protocol.















  Damodaran                Expires 7 October 2026                [Page 10]


  Internet-Draft         PTV Attested Agent Identity            April 2026


          +==================+================+=====================+
          | Metric           | Observed Value | Conditions          |
          +==================+================+=====================+
          | Proof generation | ~187ms         | Prototype, n=10,000 |
          |                  |                | (illustrative)      |
          +------------------+----------------+---------------------+
          | Proof            | <5ms           | Single proof        |
          | verification     |                | (prototype)         |
          +------------------+----------------+---------------------+
          | Raw proof size   | <300 bytes     | Groth16 (BN254) in  |
          |                  |                | prototype           |
          +------------------+----------------+---------------------+

                  Table 2: Prototype Performance Observations

  5.  Security Considerations

     This section discusses security and privacy considerations for the
     PTV protocol.

  5.1.  Freshness and Replay

     All PTV attestations MUST include a nonce provided by the relying
     party or verifier.  The nonce MUST be cryptographically random (see
     [RFC4086]) and MUST NOT be reused across attestation sessions.
     Timestamps SHOULD be included and checked against a deployment-
     specific freshness window (RECOMMENDED: less than or equal to 300
     seconds).

  5.2.  Zero-Knowledge Proof Mechanism

     PTV is designed to be compatible with zero-knowledge proof systems
     but does not mandate a specific construction.

     The predicate being proven MUST be specified, for example: "the hash
     of the agent configuration matches an enrolled value".

     The zero-egress property of ZK-proofs aligns with Privacy by Design
     principles.  Deployers SHOULD assess compliance with applicable
     regulations; this protocol is designed to facilitate such assessments
     but does not constitute legal certification.

  5.3.  Identity Misbinding

     Attestations SHOULD be bound to the specific agent instance using a
     hardware root of trust (TPM 2.0 or Secure Enclave).  Software-only
     attestations are NOT RECOMMENDED for high-assurance deployments.




  Damodaran                Expires 7 October 2026                [Page 11]


  Internet-Draft         PTV Attested Agent Identity            April 2026


  5.4.  Denial of Service

     Verifiers SHOULD implement rate limiting and proof caching to
     mitigate DoS attacks.

  6.  Interoperability and Future Work

  6.1.  EAT

     When Entity Attestation Tokens (EAT, [RFC9711]) are present, PTV
     evidence and proofs SHOULD map to EAT claims such as eat_nonce,
     swname, and swversion.  PTV evidence/proofs are also intended to be
     usable within SEAT/ExPAT-style exported attestation mechanisms.  A
     future revision of this document may define a concrete mapping.

  6.2.  Layering and Composition

     PTV is designed to compose with complementary protocols that address
     different parts of the agentic trust chain.  Specifically:

     *  PTV provides attested agent identity and model/policy binding at
        exercise time (the "who and what is running" layer),
     *  The Human Delegation Provenance Protocol (HDP) [HDP] establishes
        signed delegation provenance anchored to a human principal (the
        "who authorized what" layer), and
     *  SCITT-based execution receipts or Execution Outcome Verification
        (EOV) provide evidence of what the agent actually produced (the
        "what was done" layer).

     A natural composition point is for an EOV receipt to reference a hash
     of an HDP delegation record as its delegation token, rather than
     duplicating the full provenance chain.  Future revisions of this
     document may describe concrete mappings once the HDP and EOV models
     stabilize.

  6.3.  SCITT and Execution Receipts

     PTV is intended to compose with SCITT as follows:

     *  PTV/SEAT provide attested agent identity and state at exercise
        time, and
     *  SCITT COSE_Sign1 statements carry execution receipts for actions
        with external effects.

     Three open standardization gaps remain, treated as future work:

     1.  A registered COSE header label for the behavioral fingerprint.
     2.  A standardized format for behavior probes / fingerprints.



  Damodaran                Expires 7 October 2026                [Page 12]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     3.  A live transparency service for cross-domain execution logs.

  6.4.  Execution Outcome Verification

     Execution outcome verification is treated as a separate concern from
     attestation.  This version assumes that execution receipts, where
     needed, are carried by SCITT or a similar transparency mechanism.

     Delegation provenance protocols (for example HDP [HDP]) and
     execution-outcome attestation patterns are complementary to PTV and
     out of scope for this version.

  7.  IANA Considerations

     This document makes no requests of IANA.  Future revisions may
     request registration of media types, OAuth parameters, or attestation
     method registries once the protocol design has stabilized.

  8.  Normative References

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

     [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                Requirements for Security", June 2005,
                <https://www.rfc-editor.org/info/rfc4086>.

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

     [RFC8610]  Bormann, C. and H. Birkholz, "CBOR Data Definition
                Language (CDDL)", June 2019,
                <https://www.rfc-editor.org/info/rfc8610>.

     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "Entity Attestation Token (EAT)", December 2024,
                <https://www.rfc-editor.org/info/rfc9711>.

  9.  Informative References

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation ProcedureS (RATS)
                Architecture", January 2023,
                <https://www.rfc-editor.org/info/rfc9334>.





  Damodaran                Expires 7 October 2026                [Page 13]


  Internet-Draft         PTV Attested Agent Identity            April 2026


     [HDP]      Dalugoda, S., "Human Delegation Provenance Protocol (HDP):
                Cryptographic Chain-of-Custody for Agentic AI Systems",
                March 2026, <https://datatracker.ietf.org/doc/draft-
                helixar-hdp-agentic-delegation-00/>.

  Author's Address

     Anandakrishnan Damodaran
     Sovereign AI Stack
     Email: ananda.krishnan@hotmail.com
     URI:   https://github.com/anandkrshnn








































  Damodaran                Expires 7 October 2026                [Page 14]


name: draft-sharif-agent-identity-framework
rev: 00
title: Agent Identity Framework: Trust and Identity for Autonomous AI Agents
time: 2026-04-06T11:56:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-08T11:56:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698317+00:00
source: ietf
abstract:
  Autonomous artificial intelligence (AI) agents are increasingly
     performing actions that were previously the exclusive domain of
     authenticated human users: initiating financial transactions,
     querying regulated data, invoking external tools, and coordinating
     with other agents. Internet protocols designed for human-operated
     clients lack primitives to answer three fundamental questions about
     any autonomous action: which agent performed it, whether the agent
     was authorized to perform it, and whether the resulting evidence is
     independently verifiable.

     This document defines a framework for agent identity and trust
     enforcement on the Internet. It enumerates the gaps between current
     Internet standards and the requirements of autonomous agent systems,
     introduces a five-layer model (identity, authorization, attestation,
     evidence, trust) that separates concerns that are currently
     conflated, and outlines mechanisms to close specific gaps. The
     framework is intended to guide future Standards Track work and to
     provide a common vocabulary for researchers, implementers, and
     regulators.

     This document is informational. It does not define a wire protocol.
     It references existing Internet-Drafts and specifications that
     instantiate individual mechanisms within the framework.

full_text:
  Internet Engineering Task Force                                R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Informational                             April 6, 2026
  Expires: October 6, 2026


   Agent Identity Framework: Trust and Identity for Autonomous AI Agents
                  draft-sharif-agent-identity-framework-00


  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 October 6, 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.

  Abstract

     Autonomous artificial intelligence (AI) agents are increasingly
     performing actions that were previously the exclusive domain of
     authenticated human users: initiating financial transactions,
     querying regulated data, invoking external tools, and coordinating
     with other agents. Internet protocols designed for human-operated
     clients lack primitives to answer three fundamental questions about
     any autonomous action: which agent performed it, whether the agent
     was authorized to perform it, and whether the resulting evidence is
     independently verifiable.

     This document defines a framework for agent identity and trust
     enforcement on the Internet. It enumerates the gaps between current
     Internet standards and the requirements of autonomous agent systems,
     introduces a five-layer model (identity, authorization, attestation,
     evidence, trust) that separates concerns that are currently
     conflated, and outlines mechanisms to close specific gaps. The
     framework is intended to guide future Standards Track work and to
     provide a common vocabulary for researchers, implementers, and
     regulators.

     This document is informational. It does not define a wire protocol.
     It references existing Internet-Drafts and specifications that
     instantiate individual mechanisms within the framework.


  1.  Introduction


  1.1.  The Emergence of Autonomous Agents


     Large language models (LLMs) and related machine learning systems
     have made it practical to deploy software agents that operate with
     minimal human supervision. A modern autonomous agent is typically
     composed of a language model that determines what action to take
     next, a tool invocation layer that enables the model to execute
     external operations, and a scheduling or orchestration layer that
     runs the agent in a continuous loop. Agents of this form can hold
     long-running sessions with multiple services, initiate network
     connections to arbitrary endpoints, make financial transactions, read
     and write persistent data, and spawn or delegate to other agents.


     The protocols that carry agent traffic on the Internet are the same
     protocols developed for human users of web applications: HTTP
     [RFC9110], OAuth 2.0 [RFC6749], OpenID Connect, and related
     mechanisms. These protocols assume a human user behind a browser or
     mobile application, authenticating interactively at the start of a
     session and supervising the actions that follow. Autonomous agents
     violate every assumption in that model. They are not human. They do
     not authenticate interactively. They do not supervise themselves.


     This document does not debate whether autonomous agents should exist.
     They exist, they are deployed at scale, and they are already
     performing consequential actions. This document addresses the
     narrower question of what identity and trust primitives the Internet
     requires to make agent actions safe, auditable, and accountable.


  1.2.  Scope


     This document is a framework. It enumerates problems, organises them
     into layers, and describes mechanisms that close specific gaps. It
     does not define a wire protocol. Individual mechanisms referenced in
     this document are specified in separate documents, some of which are
     also referenced here as work in progress.


     This document does not propose a new identity system to replace OAuth
     2.0, OpenID Connect, or FAPI [FAPI2]. It proposes a layer of agent-
     specific identity and trust primitives that compose with existing
     standards. Where existing standards are adequate, this document says
     so. Where they are inadequate, this document describes the gap and
     outlines how it may be addressed.


     This document is not specific to any AI model architecture, agent
     framework, or vendor. The framework applies equally to agents built
     on LLMs, reinforcement learning systems, symbolic AI, or hybrid
     architectures.


  1.3.  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.4.  Document Structure


     Section terminology defines terms used throughout this document.


     Section problem states the agent identity problem and enumerates gaps
     between current Internet standards and the requirements of autonomous
     agent systems.


     Section framework introduces the five-layer framework: identity,
     authorization, attestation, evidence, and trust.


     Sections Section identity-layer through Section trust-layer describe
     each layer in detail.


     Sections Section mechanism-agent-identity-credentials through Section
     mechanism-compliance-evidence-export describe specific mechanisms
     that close individual gaps.


     Section threat-model develops a threat model for autonomous agents.


     Section security-considerations discusses security considerations.


     Section privacy-considerations discusses privacy considerations.


     Section integration describes how the framework integrates with
     existing Internet standards.


  2.  Terminology


     For the purposes of this document, the following terms apply. These
     definitions are scoped to the agent identity and trust domain. Where
     a term is also defined in an existing RFC, the meaning given here is
     additive, not contradictory.


     Autonomous Agent (or "Agent"):
        A software system that executes tasks on behalf of a principal
        without continuous interactive human supervision for each action.
        An agent typically consists of a decision-making component (which
        may be a machine learning model), a tool invocation layer, and a
        persistence or scheduling layer. Agents are distinguished from
        ordinary software clients by their capacity to decide, within
        policy constraints, which action to take next.


     Principal:
        The human, organisation, or service on whose behalf an agent acts.
        A principal authorises an agent to perform actions within a
        defined scope. Delegation from principal to agent is the
        foundation of accountability.


     Agent Identity:
        A cryptographically verifiable credential that uniquely identifies
        a specific agent instance. Agent identity is non-transferable,
        non-repudiable within its validity period, and distinct from the
        identity of the principal.


     Agent Instance:
        A specific running instance of an agent, distinguished from the
        agent implementation or the agent template. Two instances of the
        same implementation, running at the same time, have distinct agent
        identities.


     Agent Passport:
        A self-contained, signed credential that binds an agent identity
        to its public key, trust level, issuing authority, and lifecycle
        state. An agent passport is designed to be verified offline by any
        party holding the issuing authority's public key.


     Issuing Authority:
        An entity that issues agent passports and vouches for the identity
        of the agents to which it issues credentials. An issuing authority
        may be internal to an organisation (a private trust root), a
        commercial service, or a public infrastructure. This document does
        not mandate a single issuing authority model.


     Trust Level:
        A discrete classification of the assurance an issuing authority
        can provide about an agent identity. This document defines a five-
        level hierarchy (L0 through L4) ranging from unsigned to fully
        audited, described in Section mechanism-trust-levels.


     Trust Gate:
        A decision point in an agent-to-service interaction where the
        service verifies the agent's passport, checks its trust level,
        evaluates policy, and either allows or denies the requested
        operation before execution. The Trust Gate is a complement to, not
        a replacement for, traditional authorisation checks.


     Per-Operation Signing:
        Cryptographic signing applied to every individual agent operation,
        rather than once per session or once per client authentication.
        Each operation carries its own signature, nonce, and timestamp,
        making every action independently verifiable and non-repudiable.


     Delegation Chain:
        The ordered sequence of identities that authorise a specific
        action. For example: Principal (human user) -> Agent A (primary
        agent) -> Agent B (sub-agent invoked by Agent A) -> Target
        Service. Each link in the chain represents an authorisation grant.


     Tamper-Evident Audit Trail:
        A sequence of log records where each record cryptographically
        references the hash of the previous record, such that undetected
        modification of any earlier record is computationally infeasible.
        See also Certificate Transparency [RFC6962] for a related
        construction applied to TLS certificates.


     Attestation:
        A signed assertion by some party about a state of affairs. In this
        document, attestations are issued about agent identities, agent
        code, agent trust levels, and agent actions. Attestation is
        distinguished from evidence (below): attestation is a claim,
        evidence is an artifact that can be verified independently of the
        claim.


     Evidence:
        A cryptographically verifiable artifact that records a specific
        state of affairs. Evidence is verifiable without reference to the
        identity or trustworthiness of the party that produced it. For
        example, a SHA-256 hash of a file is evidence of the file's
        contents; it does not depend on who computed the hash.


     Trust:
        A policy decision by one party to accept the claims or actions of
        another. Trust is distinct from identity (which is what a party
        is) and from attestation (which is what a party says about itself
        or another party). Trust incorporates historical behaviour, peer
        attestations, and policy.


     MCP:
        Model Context Protocol, an open protocol for connecting large
        language models to external tools, data sources, and services. MCP
        defines a JSON-RPC 2.0 message format carried over HTTP or stdio.
        MCP does not define cryptographic identity, signing, or trust
        enforcement; those are addressed by the mechanisms referenced in
        this document.


     MCPS:
        Model Context Protocol Secure, a cryptographic security profile
        for MCP that adds per-message signing, passport-based identity,
        replay protection, trust levels, and tool integrity verification
        to the baseline MCP wire format [MCPS].


  3.  The Agent Identity Problem


  3.1.  Why Existing Standards Are Insufficient


     The Internet has mature identity and authorization standards. OAuth
     2.0 [RFC6749] handles delegated authorization for client
     applications. OpenID Connect extends OAuth for user authentication.
     JSON Web Tokens (JWTs) [RFC7519] provide a format for conveying
     claims. FAPI 2.0 [FAPI2] profiles these for high-assurance use cases
     such as banking. Mutual TLS [RFC8705] provides sender-constrained
     tokens. These standards are well understood, widely deployed, and
     suitable for their intended purpose.


     Their intended purpose does not include autonomous agents.


     The gap can be stated precisely. Existing identity standards answer
     the question "is this client authorised to make this request on
     behalf of this user?" They do not answer the question "is this
     specific autonomous agent, acting within its policy envelope,
     authorised to take this specific action, and can the action be
     independently verified after the fact?"


     The difference is not semantic. It is structural. OAuth's model
     assumes a known, pre-registered client. An autonomous agent is not a
     pre-registered client; it is software running inside a pre-registered
     client, making decisions that the pre-registered client did not
     explicitly enumerate. OAuth's scopes are pre-declared at registration
     time. An agent's actions are selected at runtime by a language model.
     OAuth's audit trail identifies the client, not the agent instance.
     OAuth's revocation affects the client, not individual agents running
     under it.


     In short: OAuth authenticates the container. It does not authenticate
     what runs inside the container and makes decisions.


     Similar gaps exist throughout the identity stack. TLS client
     certificates identify the machine, not the process. API keys identify
     the application, not the runtime instance. Session cookies [RFC6265]
     bind to a browser, not to an autonomous decision loop. Every
     mechanism in current use assumes that the decision to take an action
     is made by a human, supervised by a human, or at least authorised in
     advance by a human for a narrow class of actions. None of these
     assumptions hold for autonomous agents.


  3.2.  Why This Problem Cannot Be Solved at the Application Layer


     A natural objection to this framing is that agent identity should be
     handled by agent developers in application code. Each agent can sign
     its actions, maintain its own audit log, and self-attest its trust
     level. No new standards are required.


     This objection is incorrect for the same reasons that TLS could not
     have been solved by each application implementing its own encryption.
     There are four specific failure modes.


     First, inconsistency. If agent identity is handled at the application
     layer, every agent developer makes independent choices about signing
     algorithms, key rotation, revocation mechanisms, and audit formats.
     Interoperability is impossible. A service that receives a signed
     action from an agent built on framework A cannot verify an action
     from an agent built on framework B, because the signature formats and
     verification paths differ.


     Second, adoption. Application-layer solutions depend on developer
     action. Every existing application-layer security initiative that
     required developer action has had inconsistent adoption: CSRF tokens,
     subresource integrity, security headers, content security policies.
     HTTPS became near-universal only when the platform (web browsers,
     cloud providers, CAs issuing free certificates) enforced it. Agent
     identity will follow the same path. Platform-level enforcement is the
     only mechanism that achieves consistent adoption.


     Third, trust root. Application-layer solutions do not provide a
     shared trust root. An agent that signs its actions with a key it
     generated at runtime is making a claim that the verifying party has
     no basis to accept. A trust root establishes the chain from agent
     identity to a verifiable issuing authority. Trust roots cannot be
     bootstrapped purely in application code.


     Fourth, audit. Application-layer audit is not tamper-evident by
     default. An agent that maintains its own audit log can be modified to
     write whatever log entries serve the agent operator. Only
     cryptographic chaining (references to prior records) and external
     anchoring provide tamper evidence. These primitives must be
     consistent across agents to be useful.


  3.3.  Quantifying the Problem


     As of early 2026, the Model Context Protocol ecosystem comprises
     thousands of publicly addressable MCP servers. A survey of 1,900+
     indexed MCP servers conducted by the author in April 2026 found that
     99.4 percent of these servers implement no cryptographic identity
     verification, no message signing, and no replay protection. Agents
     connecting to these servers have no means of verifying that a
     response is genuine, that a tool definition has not been tampered
     with, or that a server is the one it claims to be.


     During the same period, the author filed six Common Vulnerabilities
     and Exposures (CVEs) against components of the MCP ecosystem,
     covering resource exhaustion, unbounded memory allocation, and
     related issues affecting packages with tens of millions of weekly
     downloads. These are not exceptional findings. They reflect the state
     of an ecosystem that has grown faster than its security primitives.


     The quantitative point is not that the MCP ecosystem is uniquely
     insecure. The quantitative point is that the ecosystem has adopted
     the conventions of unauthenticated HTTP services because the
     alternative (developers implementing cryptographic identity
     independently at the application layer) is not feasible at scale.


  3.4.  The Cost of Inaction


     The cost of the status quo is not limited to the MCP ecosystem.
     Autonomous agents are being deployed in financial services,
     healthcare, government, and critical infrastructure. Each deployment
     extends the attack surface of the organisation that hosts it, in ways
     that existing identity and authorization systems were not designed to
     contain.


     Specific costs include:


     Financial exposure: an agent making unauthorised payments cannot be
     halted mid-transaction by revoking a user session, because the agent
     does not depend on a user session for authorisation.


     Regulatory exposure: compliance frameworks such as the EU AI Act [EU-
     AI-Act] (Articles 12, 13, 14, 15, and 50) require logging,
     transparency, human oversight, accuracy, and identification for AI
     systems. Current logging infrastructure does not distinguish between
     actions taken by an agent and actions taken by the user on whose
     behalf the agent is running. This undermines the audit requirements
     that regulators rely on.


     Forensic exposure: when an incident occurs involving an agent,
     investigators must reconstruct what the agent did, when, on whose
     behalf, and with what authorisation. Current logs answer these
     questions for human users. They do not answer them for agents.


     Systemic risk: as agents proliferate and begin invoking other agents,
     cascades of automated action can propagate errors or attacks faster
     than human operators can respond. Without identity and trust
     primitives that work at agent granularity, containment is impossible.


     The cost of inaction is not measured in a single incident. It is
     measured in the progressive loss of the ability to answer, after any
     incident, the question of what happened and who was responsible.


  4.  Framework Overview: Five Layers of Agent Trust


  4.1.  Separation of Concerns


     Current discussions of agent security often conflate concerns that
     should be distinct. This document separates them into five layers.


     The layers form a stack. Each layer depends on the ones below it and
     provides services to the ones above it. The figure below shows the
     stack and the question each layer answers.


        +----------------------------------------------+
        |  Layer 5: Trust                              |
        |  "Should the actor be trusted going forward?"|
        |  Inputs: history, peer attestations, policy  |
        +----------------------------------------------+
                             ^
                             |
        +----------------------------------------------+
        |  Layer 4: Evidence                           |
        |  "What can be independently verified?"       |
        |  Artifacts: hash chain, bindings, timestamps |
        +----------------------------------------------+
                             ^
                             |
        +----------------------------------------------+
        |  Layer 3: Attestation                        |
        |  "Who says so?"                              |
        |  Signed claims about identity, code, actions |
        +----------------------------------------------+
                             ^
                             |
        +----------------------------------------------+
        |  Layer 2: Authorization                      |
        |  "Is the actor permitted?"                   |
        |  Scope + policy + Trust Gate decision        |
        +----------------------------------------------+
                             ^
                             |
        +----------------------------------------------+
        |  Layer 1: Identity                           |
        |  "Who is acting?"                            |
        |  Cryptographic credentials + issuing root    |
        +----------------------------------------------+

              Figure 1: The Five-Layer Agent Trust Stack


     Each layer is a distinct concern and can be reasoned about
     independently of the others. However, a complete system composes all
     five; skipping a layer creates a gap that adversaries will find and
     exploit. Each layer answers a different question. Each layer requires
     different primitives. Each layer can be implemented, deployed, and
     reasoned about independently of the others, though composition across
     layers is essential for a complete system.


     The five layers, in the order in which they apply to any action, are:


     1. Identity: who is acting? 2. Authorization: is the actor permitted?
     3. Attestation: who says so? 4. Evidence: what can be independently
     verified about this action? 5. Trust: should the actor be trusted
     going forward?


     The layers are presented in order because they reflect the sequence
     in which any decision about an agent action must be made. First, the
     verifying party must determine who is acting. Then it must determine
     whether the actor is permitted to take this action. If permitted, the
     action proceeds and produces evidence. The outcome feeds back into a
     trust judgement that informs future decisions.


  4.2.  The Importance of Separating Evidence from Attestation


     A consequence of the layered model is that evidence and attestation
     must not be confused. Attestation is a claim by some party; its value
     depends on the trustworthiness of the claimant. Evidence is an
     artifact that can be verified independently of the claimant's
     trustworthiness; its value depends on the verifiability of the
     artifact itself.


     For example, an agent's self-report that it executed a database query
     successfully is an attestation. A cryptographic hash of the exact
     request and response, signed at the time the action occurred, bound
     to a hash of the previous such record, is evidence. The attestation
     can be revised later. The evidence cannot.


     This distinction is critical because systems that conflate the two
     concepts end up with neither. A system that accepts attestations as
     evidence cannot prove anything after the fact. A system that demands
     evidence for every attestation is unusable in practice. The correct
     approach is to provide both, at different layers, with clear
     interfaces between them.


  4.3.  Why Five Layers


     The choice of five layers is not arbitrary. It reflects five
     questions that any complete agent trust system must answer, and each
     question requires different technical primitives.


     Identity requires cryptographic credentials, a key management system,
     and an issuing authority model.


     Authorization requires a policy language, a decision point, and a
     mechanism for expressing and evaluating scopes.


     Attestation requires a signing key and a format for asserting claims.


     Evidence requires tamper-evident storage, time ordering, and a
     mechanism for external verification.


     Trust requires reputation accumulation, peer attestations, and a
     policy mechanism for combining historical signals into a current
     decision.


     These five primitive sets are necessary and collectively sufficient
     for the agent trust problem. Fewer layers conflate concerns that must
     be separated. More layers over-decompose and make reasoning harder.


  5.  The Identity Layer


  5.1.  Purpose


     The identity layer answers the question: who is acting? For an
     autonomous agent, this question has several parts.


     Which agent instance is making this request? Two instances of the
     same agent implementation, running simultaneously, are distinct
     actors. They MUST have distinct identities.


     Which agent implementation is this instance running? The
     implementation is the code and model that define the agent's
     capabilities and behaviour.


     Which principal authorised this agent? The principal is the human,
     organisation, or service on whose behalf the agent is acting. Agent
     identity does not replace principal identity; it supplements it.


     Who issued the agent's identity? The issuing authority vouches for
     the agent's identity. Verification of agent identity requires
     verifying the issuing authority's assertion.


  5.2.  Requirements


     An identity layer for autonomous agents MUST satisfy the following
     requirements.


     R1: Non-transferability. An agent identity MUST be bound to a
     specific agent instance. It MUST NOT be possible to transfer an agent
     identity to a different instance without the issuing authority's
     consent.


     R2: Non-repudiation. An action signed with an agent identity MUST NOT
     be later disavowable by the agent or its operator. The signature
     itself provides cryptographic evidence of the action.


     R3: Time-bound validity. Agent identities MUST have explicit issuance
     and expiration times. An identity that has no expiration time is
     equivalent to a permanent credential, which violates the principle of
     least privilege.


     R4: Offline verifiability. It MUST be possible to verify an agent
     identity without contacting the issuing authority for every
     verification. A design that requires online verification on every
     action creates a dependency and a bottleneck that are incompatible
     with distributed systems.


     R5: Distinct from principal identity. Agent identity MUST be distinct
     from the identity of the principal. The system MUST NOT conflate "the
     user logged in" with "the agent is acting on the user's behalf."


     R6: Revocability. It MUST be possible to revoke a specific agent
     identity without revoking the principal's session or the identity of
     other agents running under the same principal.


     These requirements collectively rule out several approaches that are
     sometimes proposed. They rule out using the principal's OAuth token
     as the agent identity (fails R5, R6). They rule out using a static
     API key (fails R1, R3). They rule out using a server-side session
     cookie (fails R4). They rule out using TLS client certificates
     without modification (fails R1 at the instance granularity, fails
     R6).


  5.3.  Cryptographic Basis


     An agent identity credential is, at minimum, a public key, a binding
     to an identifier, a signature by an issuing authority, and associated
     metadata (issuance time, expiration time, trust level, principal).
     The public-private key pair used to generate signatures MUST be
     generated in a manner consistent with current cryptographic best
     practice; at the time of writing, ECDSA over NIST P-256 [FIPS186-5]
     is recommended for new deployments due to its balance of security,
     performance, and interoperability. Implementations MAY support
     additional algorithms.


     Signatures SHOULD use IEEE P1363 fixed-length format (64 bytes for
     P-256), with low-S normalisation to prevent signature malleability.
     JSON payloads to be signed SHOULD be canonicalised per [RFC8785]
     before signing, so that verification is deterministic regardless of
     JSON serialisation choices.


     Private keys corresponding to agent identities MUST be protected
     against exfiltration. In high-assurance deployments, private keys
     SHOULD be held in a hardware security module (HSM), trusted execution
     environment (TEE), or equivalent. In lower-assurance deployments,
     private keys MAY be held in the agent's memory, but the operator
     SHOULD ensure that memory dumps cannot be obtained by unauthorised
     parties.


  5.4.  The Agent Passport


     An agent passport is the concrete artifact that carries agent
     identity. This framework does not mandate a single passport format,
     but describes the minimum content.


     The passport is a self-contained signed document. It travels with the
     agent and can be verified offline by any party that holds the issuing
     authority's public key. The figure below illustrates the structure.


        +---------------------------------------------------+
        |                 Agent Passport                    |
        +---------------------------------------------------+
        |  passport_id : asp_<32 hex chars>                 |
        |  agent_name  : "procurement-bot"                  |
        |  version     : "1.0.0"                            |
        |  public_key  : <PEM-encoded ECDSA P-256 key>      |
        |  issuer      : "trust-root.example.org"           |
        |  principal   : "user:alice@example.org"           |
        |  trust_level : L2                                 |
        |  issued_at   : 2026-04-06T09:00:00Z               |
        |  expires_at  : 2026-07-06T09:00:00Z               |
        |  capabilities: ["tools/call", "resources/read"]   |
        |  ---                                              |
        |  signature   : <issuer's signature over above>    |
        +---------------------------------------------------+

                     Figure 2: Agent Passport Structure


     The passport contains everything a verifier needs: the public key
     used to verify the agent's signatures, the identity of the authority
     that issued the passport, the principal whose authority the agent
     operates under, the assurance level, and the validity window.


     An agent passport is a signed data structure containing:


     * A unique passport identifier.
     * The agent's public key.
     * The agent's name or label (human-readable).
     * The agent's implementation version.
     * The issuing authority's identifier.
     * Issuance timestamp.
     * Expiration timestamp.
     * Trust level (see Section mechanism-trust-levels).
     * Optional capability declarations.
     * A signature by the issuing authority over the preceding fields.

     A passport identifier format that has been used in deployed
     implementations is the prefix "asp_" followed by 32 hexadecimal
     characters, providing 128 bits of entropy. This document does not
     mandate this format, but notes that a prefix-based scheme makes
     passport identifiers self-describing and facilitates log analysis.


     The passport is designed to be carried with every agent action. A
     verifier receiving an action signed by an agent can extract the
     passport, verify the issuing authority's signature over the passport,
     extract the agent's public key from the passport, verify the
     signature over the action, and proceed.


  5.5.  Issuing Authority Models


     This framework supports multiple issuing authority models,
     corresponding to different deployment contexts.


     Self-issued. An agent generates its own key pair and produces a self-
     signed passport. This is the simplest model and provides
     cryptographic non-repudiation but no third-party trust. It is
     appropriate for development, testing, and isolated deployments. Trust
     level L0 (see Section mechanism-trust-levels) caps self-issued
     passports.


     Private trust root. An organisation operates its own issuing
     authority, issuing passports to agents under its control.
     Verification requires the organisation's public key (the trust root)
     to be distributed to verifiers in advance. This is appropriate for
     internal deployments within an enterprise.


     Federated trust. Multiple organisations form a trust federation with
     cross-signed trust roots, allowing agents from one organisation to be
     verified by verifiers in another. This model is compatible with
     existing federation standards.


     Public trust root. A public service operates an issuing authority
     that any party can use. Verification requires the public service's
     trust root, which is distributed through well-known infrastructure
     analogous to how Certificate Authority (CA) roots are distributed in
     the WebPKI.


     This framework does not mandate any single model. It does require
     that the model in use MUST be discoverable by verifying parties.


  6.  The Authorization Layer


  6.1.  Purpose


     The authorization layer answers the question: is the actor permitted?
     It takes as input an agent identity (from the identity layer) and a
     proposed action, and produces a decision: ALLOW or DENY.


     In the human-user case, authorization is typically based on roles and
     scopes. A user has a role (e.g., "administrator"), a role has
     permissions, permissions are checked at runtime. OAuth 2.0 scopes
     generalise this: a client is granted specific scopes by the user at
     consent time, and the service checks the scopes on each request.


     Agent authorization requires more than this. Because agents select
     their actions at runtime, coarse pre-granted scopes cannot adequately
     express the boundary between permitted and forbidden behaviour. An
     agent granted "read access to the user's calendar" is either granted
     too much (any calendar action) or is blocked from actions the user
     would have approved in advance (creating calendar entries on the
     user's behalf). Neither extreme is satisfactory.


  6.2.  Requirements


     An authorization layer for autonomous agents MUST satisfy the
     following requirements.


     A1: Fine granularity. Authorization decisions MUST be possible at the
     level of individual operations (e.g., specific tool invocations,
     specific API endpoints, specific data scopes), not only at the level
     of entire resources or client applications.


     A2: Runtime evaluation. Authorization MUST be evaluable at the time
     of each action, not only at session establishment. An authorization
     decision made at session start cannot account for the actions the
     agent chooses to take later.


     A3: Contextual parameters. Authorization decisions MUST be able to
     incorporate parameters beyond identity: time of day, spending limits,
     counterparty identity, request size, cumulative usage since a
     previous baseline.


     A4: Delegation awareness. When agent A invokes agent B on behalf of
     principal P, the authorization decision on agent B's action MUST
     incorporate the delegation chain: whether P authorised A to delegate
     to B, the limits of that delegation, and whether B's action is within
     those limits.


     A5: Policy expression in a standard form. Authorization policies MUST
     be expressible in a portable format so that they can be audited,
     versioned, reviewed, and transferred between systems without reverse
     engineering.


     A6: Fail-closed default. In the absence of an explicit allow
     decision, the default MUST be deny. This is the standard fail-closed
     pattern and protects against policy oversight.


  6.3.  Beyond Pre-granted Scopes


     Existing OAuth-style scopes do not satisfy A1 through A5. OAuth
     scopes are typically coarse-grained ("read", "write"), are granted at
     consent time (not runtime), and cannot easily express contextual
     parameters such as spending limits or delegation depth. Extending
     OAuth scopes to cover these cases has been attempted (RAR, Rich
     Authorization Requests; XACML, eXtensible Access Control Markup
     Language; ALFA; OPA, Open Policy Agent) with mixed adoption.


     This framework takes the view that a complete solution requires three
     distinct components: a scope expression language (for describing what
     an agent may do), a consent mechanism (for translating a principal's
     intent into concrete scopes), and a decision point (for evaluating
     actions against scopes at runtime). Individual mechanisms for these
     components are discussed in Section mechanism-agent-scope-expression
     and Section mechanism-fine-grained-consent.


  6.4.  The Trust Gate


     A specific decision point pattern that this framework names
     explicitly is the Trust Gate.


     The Trust Gate sits at the boundary of a service that accepts agent
     traffic. Incoming requests pass through the gate before reaching
     business logic. The gate performs identity verification, trust level
     check, policy evaluation, and contextual parameter evaluation. It
     produces a structured allow or deny decision and logs its reasoning.


              Agent Request
                   |
                   v
        +-------------------------+
        |      Trust Gate         |
        |                         |
        |  1. Verify passport     |-------> Invalid signature -> DENY
        |  2. Check trust level   |-------> Below threshold  -> DENY
        |  3. Evaluate policy     |-------> Policy violation -> DENY
        |  4. Check context       |-------> Spending limit   -> DENY
        |  5. Check revocation    |-------> Revoked          -> DENY
        |                         |
        +-------------------------+
                   |
                   | ALLOW
                   v
        +-------------------------+
        |     Business Logic      |
        |  (executes the action)  |
        +-------------------------+
                   |
                   v
        +-------------------------+
        |    Evidence Layer       |
        |  (logs hash-chained     |
        |   audit entry)          |
        +-------------------------+

                Figure 3: Trust Gate Decision Flow


     The Trust Gate is a reusable pattern. Services that accept agent
     traffic should implement it as middleware, not inline in business
     logic. Centralising the decision point ensures consistent policy
     enforcement and provides a single point at which auditing, logging,
     and rate limiting are applied. The Trust Gate is a decision point at
     the boundary of a service, invoked before any requested operation is
     executed, that takes as input the agent's passport, the requested
     operation, and contextual parameters, and produces an allow/deny
     decision.


     The Trust Gate is distinct from traditional authorization in one
     important respect: it evaluates trustworthiness in addition to
     permission. A traditional authorization check asks "is this identity
     permitted to perform this operation?" The Trust Gate additionally
     asks "is this identity's current trust level sufficient for this
     operation?" An agent that is permitted to execute a payment but has
     accumulated anomalous behaviour signals may be rejected by the Trust
     Gate even though it would be permitted by a role-based check. This
     permits policy decisions that blend identity, authorization, and
     behavioural signals.


     Trust Gates are intended to be implemented as middleware in services
     that accept agent traffic, analogous to how rate limiting or HMAC
     verification are implemented today. They operate before business
     logic and return a structured decision that business logic may
     consult.


  7.  The Attestation Layer


  7.1.  Purpose


     The attestation layer answers the question: who says so? When an
     agent makes a claim about itself (its identity, its code, its policy,
     its prior actions), the claim must be attributable to someone whose
     trustworthiness can be evaluated.


     Attestation is distinguished from evidence at the next layer.
     Attestation is a claim made by a party: "I am agent X", "I executed
     action Y", "my code hash is Z". Evidence is a verifiable artifact
     that does not depend on a claim. A signed passport is an attestation
     by the issuing authority. A hash-chained log record is evidence.


  7.2.  Categories of Attestation


     This framework distinguishes four categories of attestation that are
     relevant to agents.


     Identity attestation. The issuing authority attests that a given
     public key belongs to a given agent identity. This is carried in the
     passport.


     Code attestation. A party (the agent operator, or a trusted verifier
     such as a remote attestation service) attests that the agent's code
     is a specific known version, with a specific known hash. Code
     attestation supports the claim that the agent has not been tampered
     with or replaced since it was audited.


     Action attestation. The agent signs each action it takes. The
     signature is an attestation by the agent (under the identity vouched
     for by its issuing authority) that the specific action, with specific
     parameters, at a specific time, was performed by this agent.


     Trust attestation. A third party (another agent, a peer service, a
     reputation system) attests to the trustworthiness of a given agent.
     Peer attestations form the basis of distributed trust scoring.


  7.3.  Requirements


     An attestation layer for autonomous agents MUST satisfy the following
     requirements.


     AT1: Cryptographic signing. Every attestation MUST be
     cryptographically signed. Unsigned claims are not attestations in
     this framework's sense.


     AT2: Inclusion of identity. Every attestation MUST include a
     reference to the identity of the attesting party. An attestation that
     does not identify its source cannot be evaluated for trustworthiness.


     AT3: Inclusion of time. Every attestation MUST include a timestamp.
     The timestamp is a claim by the attester about when the attestation
     was made; it is not itself evidence (unless anchored externally, as
     discussed in Section evidence-layer).


     AT4: Scope. Every attestation MUST state clearly what is being
     attested. A signed blob without a clear statement of meaning is not
     an attestation; it is a signature with no semantic content.


     AT5: Relation to prior attestations. Where applicable, attestations
     SHOULD reference prior related attestations. This allows a chain of
     attestations to be constructed (for example, a sequence of actions by
     the same agent over time).


  7.4.  Attestation Is Not Enough


     A system that relies only on attestations (without the evidence layer
     below) has an obvious failure mode: a compromised agent, or an agent
     whose operator is malicious, can issue attestations about anything.
     The attestations will be cryptographically valid but semantically
     false.


     This is why the framework separates attestation from evidence.
     Attestation at minimum provides non-repudiation (a party cannot later
     disavow a signed claim). But non-repudiation alone is insufficient
     when the adversary is the attester. Evidence, as discussed in the
     next layer, provides a verification path that does not depend on the
     attester's honesty.


  8.  The Evidence Layer


  8.1.  Purpose


     The evidence layer answers the question: what can be independently
     verified about this action? Evidence is an artifact that, once
     produced, can be checked for correctness without reference to the
     party that produced it.


     The canonical example is a cryptographic hash. A SHA-256 hash of a
     file is evidence of the file's contents: anyone with the file can
     recompute the hash and confirm that the hash matches. The party who
     computed the hash originally need not be trusted. The hash itself is
     the evidence.


     Evidence differs from attestation in that evidence does not require
     the producer to be trusted. It is a deliberately lower bar than
     attestation, and therefore a stronger guarantee.


  8.2.  Minimal Evidence Bundle for an Agent Action


     This framework proposes that every agent action SHOULD produce a
     minimal evidence bundle containing at least the following.


     The evidence bundle structure is shown below. It is deliberately
     minimal: it contains hashes and identifiers, not payloads. This
     reduces the privacy surface of the audit trail while preserving the
     ability to verify that a specific action occurred.


        +---------------------------------------------------+
        |           Evidence Bundle (entry N)               |
        +---------------------------------------------------+
        |  seq         : N                                  |
        |  timestamp   : 2026-04-06T10:00:00.123Z           |
        |  agent_id    : asp_a1b2c3...                      |
        |                                                   |
        |  request_hash  : sha256(canon(request_params))    |
        |  response_hash : sha256(canon(response_body))     |
        |  binding_hash  : sha256(request_hash||response    |
        |                         _hash)                    |
        |                                                   |
        |  prev_hash   : <binding_hash of entry N-1>        |
        |  entry_hash  : sha256(canon(all above fields))    |
        +---------------------------------------------------+
                             |
                             | prev_hash link
                             v
        +---------------------------------------------------+
        |           Evidence Bundle (entry N+1)             |
        +---------------------------------------------------+
        |  seq         : N+1                                |
        |  prev_hash   : <entry_hash of entry N>            |
        |  ...                                              |
        +---------------------------------------------------+

                    Figure 4: Evidence Bundle Chain


     The hash chain is the heart of the tamper-evident property. Modifying
     entry N requires recomputing entryhash for N, which breaks the
     prevhash reference in entry N+1, which breaks N+1's entry_hash, and
     so on to the end of the chain. Undetected modification requires
     rewriting every subsequent entry; detecting the modification requires
     only comparing a known root hash against a recomputed one.


     Request hash. A cryptographic hash of the canonicalised request
     payload (the parameters of the action).


     Response hash. A cryptographic hash of the canonicalised response
     payload (the result of the action, or the error).


     Binding hash. A cryptographic hash of the canonicalised concatenation
     of the request hash and the response hash. This binds the request and
     response together, such that it is infeasible to substitute either
     one independently without detecting the substitution.


     Timestamp. The time at which the action was performed, ideally
     anchored against an external time source.


     Prior hash. A reference to the binding hash of the previous action by
     the same agent, forming a hash chain.


     These fields, and only these fields, provide the minimal guarantee
     that a specific request and response pair occurred at a specific
     time, in a specific order relative to other actions by the same
     agent. They do not prove that the action was authorised, or that the
     agent was legitimate, or that the action was the one the principal
     intended. Those claims are at higher layers. The evidence layer
     provides only the narrow technical claim that a specific artifact
     pair is bound together and ordered.


     The evidence bundle is deliberately minimal. Additional metadata (the
     agent identity, the issuing authority, policy context) can be added
     at higher layers and verified separately. Keeping the evidence layer
     minimal ensures that the evidence remains verifiable even when higher
     layers are compromised or unavailable.


  8.3.  Tamper-Evident Audit Trail


     Individual evidence bundles are valuable. A sequence of evidence
     bundles, chained together, is more valuable. A tamper-evident audit
     trail is a sequence of records where each record's hash includes a
     reference to the previous record's hash, such that modification of
     any record invalidates all subsequent records.


     This is the construction used by Certificate Transparency [RFC6962]
     to provide public audit of TLS certificate issuance. The same
     construction applies to agent actions. A verifier can check that an
     audit trail has not been tampered with by recomputing the chain from
     a known good root to the current record.


     An audit trail alone does not prove that records have not been added
     or that early records are genuine. It only proves that the sequence
     has not been modified since a known point in time. To achieve
     stronger guarantees, the audit trail should be externally anchored:
     root hashes should be committed to an external witness (for example,
     a blockchain, a trusted time-stamping service, or a public append-
     only log) at regular intervals. External anchoring converts a local
     audit trail into a globally verifiable record.


  8.4.  Integration with SIEM and Forensic Systems


     Agent audit trails SHOULD be exportable in standard formats
     consumable by Security Information and Event Management (SIEM)
     systems and forensic analysis tools. Common formats include syslog
     [RFC5424], Common Event Format (CEF), JSON Lines, and vendor-specific
     formats. The export format is a presentation concern and does not
     affect the underlying audit guarantees.


  9.  The Trust Layer


  9.1.  Purpose


     The trust layer answers the question: should the actor be trusted
     going forward? Trust is a policy decision that takes as input an
     actor's identity, attestations about the actor, evidence of the
     actor's past behaviour, and peer assessments, and produces a trust
     score or trust level that informs future decisions about the actor.


     Trust is the most subjective of the five layers, and the layer where
     policy choices must be made by the deploying organisation. This
     framework does not prescribe a specific trust function. It describes
     the inputs, the properties the function should have, and the ways
     trust interacts with the other layers.


  9.2.  Inputs to Trust


     A trust function operates on at least the following inputs.


     Identity history. How long has this agent been known to the verifying
     party? Newly issued identities are inherently less trusted than
     identities with a track record.


     Behavioural history. What has the agent done? Have its actions been
     consistent with stated policy? Are there anomalies (unusual operation
     counts, unusual hours, unusual counterparties)?


     Peer attestations. Have other parties in the trust ecosystem issued
     attestations about this agent? Negative attestations (reports of
     policy violations) reduce trust; positive attestations (successful
     transactions, audit passes) increase trust.


     Code attestation. Does the agent run a known, attested version of the
     implementation? An agent whose code has not been verified is less
     trusted than one whose code has.


     Issuing authority standing. Is the issuing authority that vouched for
     this agent itself trusted? Trust propagates through the issuance
     chain.


  9.3.  Properties of a Good Trust Function


     Without mandating any specific implementation, this framework
     identifies properties that a trust function should have.


     Monotonicity under good behaviour. Actions consistent with policy
     should increase trust (with diminishing returns). Actions
     inconsistent with policy should decrease trust.


     Asymmetry. Trust should decrease faster than it increases. A single
     serious violation should reduce trust more than it could be built up
     by a single positive action.


     Transparency. The inputs and outputs of the trust function should be
     transparent to the agent operator. Opaque trust systems cannot be
     audited or contested.


     Due process. An agent that is about to be denied based on trust
     should have the opportunity to learn why (at some level of
     granularity) and to dispute the decision. This is analogous to the
     due process requirements on credit scoring in many jurisdictions.


     Resistance to manipulation. The trust function should be robust
     against collusion (multiple agents issuing positive attestations
     about each other to inflate trust) and Sybil attacks (a single
     operator creating many agents to dilute negative signals).


  9.4.  Trust Levels


     This framework defines a discrete five-level trust hierarchy (L0
     through L4) described in Section mechanism-trust-levels. Discrete
     levels are easier to reason about than continuous scores and are
     easier to express in policy. Continuous scores may be appropriate for
     internal trust calculations but should be mapped to discrete levels
     for external consumption.


  9.5.  Trust Is Not a Moral Judgement


     A frequent misunderstanding of trust systems is that they are making
     a moral judgement about the agent. They are not. Trust in this
     framework is a policy decision by one party about whether to accept
     actions from another, based on observable behaviour. It is a
     technical construct, not a verdict.


     This matters because trust decisions must be contestable. An agent
     that is denied at a Trust Gate because of low trust should have
     recourse: the ability to ask why, the ability to challenge false
     signals, the ability to accumulate positive signals that restore
     trust over time. A trust system without recourse is a blacklist.


  10.  Mechanisms


     The preceding sections describe the framework in the abstract. This
     section describes specific mechanisms that close specific gaps within
     the framework. Each mechanism is described at the level of
     requirements and interfaces; detailed wire formats are in separate
     documents.


  10.1.  Agent Identity Credentials


     An agent identity credential is the concrete artifact carrying an
     agent passport. The credential contains the agent's public key,
     metadata, and a signature by the issuing authority.


     OpenID Connect provides a foundation for extending user identity to
     agents. An extension (see [I-D.sharif-openid-agent-identity]) defines
     additional claims that identify an actor as an agent, bind the agent
     to a principal, and carry agent-specific attributes.


     The mechanism integrates with OAuth 2.0 token endpoints, OIDC
     Discovery, and JWKS endpoints. Existing identity infrastructure can
     issue agent credentials with minimal modification; the primary change
     is the addition of new claim types and the agent-specific token
     profile.


  10.2.  Delegation Chains


     When agent A invokes agent B on behalf of principal P, the resulting
     action must be attributable to all three parties (P, A, and B) and
     bounded by the authority each granted to the next.


     The figure below illustrates a delegation chain from a human
     principal through two agents to a target service. Each arrow carries
     a signed authorisation grant. The target service reconstructs the
     chain from the bottom up and verifies that each link is signed by the
     party named in the previous link.


        +--------------------+
        |     Principal      |
        |    Alice (human)   |
        +--------------------+
                  |
                  | grants authority to
                  | Agent A with scope S_A
                  v
        +--------------------+
        |      Agent A       |
        |  "procurement-bot" |
        +--------------------+
                  |
                  | delegates subset of S_A
                  | to Agent B with scope S_B
                  | where S_B is a subset of S_A
                  v
        +--------------------+
        |      Agent B       |
        |  "translate-bot"   |
        +--------------------+
                  |
                  | performs action within S_B
                  | on target service
                  v
        +--------------------+
        |   Target Service   |
        |                    |
        |  Verifies chain:   |
        |  Principal -> A    |
        |  A -> B            |
        |  B -> Action       |
        |                    |
        |  Checks action     |
        |  is within S_B,    |
        |  S_B is within S_A,|
        |  S_A was granted   |
        |  by Principal.     |
        +--------------------+

                 Figure 5: Delegation Chain


     A delegation chain MUST be bounded. Infinite or unbounded delegation
     creates a denial of service risk and makes auditing impractical. A
     maximum delegation depth (this framework recommends 5 hops as a
     default, configurable per deployment) limits the chain.


     Each link in the chain MUST carry its own cryptographic binding: the
     delegating party signs an assertion that includes the delegatee's
     identity, the scope of the delegation, the expiration time, and the
     prior link in the chain. Verification proceeds from the terminal
     action backwards through the chain to the principal.


     OAuth 2.0 Token Exchange [RFC8693] provides a starting point. It
     defines a flow in which one token can be exchanged for another that
     is narrower in scope and represents a new actor. For agent
     delegation, the delegation chain is explicit: a delegated token
     carries references to its antecedents, so that the full chain can be
     reconstructed.


     A delegation chain MUST be bounded. Infinite or unbounded delegation
     creates a denial of service risk and makes auditing impractical. A
     maximum delegation depth (this framework recommends 5 hops as a
     default, configurable per deployment) limits the chain.


     Each link in the chain MUST carry its own cryptographic binding: the
     delegating party signs an assertion that includes the delegatee's
     identity, the scope of the delegation, the expiration time, and the
     prior link in the chain. Verification proceeds from the terminal
     action backwards through the chain to the principal.


  10.3.  Per-Operation Signing


     Per-operation signing requires each agent action to carry a
     cryptographic signature over the action's parameters, along with
     replay-protection metadata (nonce and timestamp).


     MCPS [MCPS] defines a specific instantiation of per-operation signing
     for the Model Context Protocol. The JSON-RPC message is wrapped in an
     envelope that contains the signature, the passport identifier, a
     nonce, and a timestamp. Canonical JSON serialisation [RFC8785] is
     used to make verification deterministic.


     The performance cost of per-operation signing is typically negligible
     for interactive traffic (under one millisecond per operation on
     modern hardware for P-256 signing), but it is not zero. High-
     throughput deployments may require batching, signature caching, or
     hardware acceleration to avoid throughput loss.


  10.4.  Trust Levels (L0 through L4)


     This framework defines five discrete trust levels. The levels are
     hierarchical: L4 is the highest, L0 is the lowest. Each level adds
     specific requirements on top of the level below it.


        Trust Level        Criteria                    Typical Use
        -----------        --------                    -----------
        L4 Audited    +--[ manual security audit ]--+  Regulated
                      |  mandatory revocation check  |  finance,
                      |  L3 criteria                 |  healthcare,
                      +------------------------------+  gov

        L3 Scanned    +--[ code origin verified   ]--+  Production
                      |  automated security scan     |  consumer
                      |  L2 criteria                 |  services
                      +------------------------------+

        L2 Verified   +--[ issuing authority in  ]---+  Standard
                      |  verifier's trust store      |  enterprise
                      |  L1 criteria                 |  deployments
                      +------------------------------+

        L1 Identified +--[ passport signed by an ]---+  Low-stakes
                      |  issuing authority           |  interactions
                      |  L0 criteria                 |
                      +------------------------------+

        L0 Unsigned   +--[ no cryptographic      ]---+  Dev, test,
                      |  identity required           |  isolated
                      |  (baseline)                  |  deployments
                      +------------------------------+

                   Figure 6: Trust Level Hierarchy


     Verifying parties declare a minimum trust level as policy. An agent
     connecting at a level below the minimum is rejected. The numeric
     levels provide a simple ordering that can be compared directly
     ("mintrust <= agenttrust").


     L0: Unsigned. The agent has no cryptographic identity. Actions are
     unsigned. This level is appropriate for development, testing, and
     isolated deployments where cryptographic identity is not required.
     Self-issued passports are capped at L0 unless explicitly trusted by a
     verifier.


     L1: Identified. The agent has a passport signed by an issuing
     authority. Actions are signed with the agent's private key. The
     verifying party can confirm that the actions are attributable to the
     specific agent identity. No additional vetting is assumed.


     L2: Verified. In addition to L1, the issuing authority's root of
     trust is in the verifier's trust store. The verifier has an explicit
     policy decision to accept this issuing authority. This is the level
     at which most production agent deployments should operate.


     L3: Scanned. In addition to L2, the issuing authority has verified
     the agent's code origin (e.g., through code signing or provenance
     attestation), and the agent has passed automated security scanning
     against a standard set of checks. The OWASP MCP Security Cheat Sheet
     [OWASP-MCP] is an example of such a check set.


     L4: Audited. In addition to L3, the agent has undergone manual
     security audit by a qualified party. Mandatory revocation signals are
     published for L4 agents, and verifiers check revocation before
     accepting L4 actions.


     Verifying parties declare a minimum trust level as policy. An agent
     connecting at a level below the minimum is rejected.


     The numeric levels are deliberate. They provide a simple ordering
     that can be compared directly ("mintrust <= agenttrust"). They do not
     imply that L4 is infinitely better than L1; they imply that L4 meets
     more specific criteria.


  10.5.  Trust Gate


     The Trust Gate is a middleware component that implements the
     authorization layer's decision point. It accepts incoming agent
     requests and produces an allow/deny decision based on identity, trust
     level, policy, and contextual parameters.


     A Trust Gate implementation typically exposes an interface such as:


     ``" decide(agent_passport, operation, parameters, context) ->
     decision "``


     where "decision" is a structured value indicating ALLOW or DENY, a
     reason code, and (in the DENY case) whether the decision is
     appealable.


     Trust Gates SHOULD be implemented as reusable middleware rather than
     inline in business logic, so that policy changes do not require
     modifying business code and so that decisions are consistently
     logged.


  10.6.  Agent Audit Trail


     The agent audit trail is a sequence of evidence records (see Section
     evidence-layer) that records every action taken by the agent. See
     [I-D.sharif-agent-audit-trail] for a detailed specification of the
     record format and chaining rules.


     Key requirements: records are append-only, hash-chained, signed, and
     exportable in standard SIEM formats. Root hashes are anchored
     externally at regular intervals to protect against unilateral
     modification of the log.


  10.7.  Agent Payment Trust


     Agent payment trust is a specific application of the framework to
     financial transactions. An agent initiating a payment goes through a
     sequence of checks: trust level verification, sanctions screening
     against external lists, spending limit enforcement, per-operation
     signing of the payment request, and non-repudiable receipt
     generation. See [I-D.sharif-agent-payment-trust] for detailed
     specification.


     This mechanism integrates with FAPI 2.0 [FAPI2] for high- assurance
     use cases. The per-operation signing requirement fits naturally with
     FAPI's existing sender-constrained token model, extending it from
     "the client that received this token" to "the specific agent
     operating within this client".


  10.8.  Agent Transport Protocols


     Two transport protocols support agent-specific communication
     patterns.


     The Agent Transport Protocol (ATP) provides asynchronous store-and-
     forward messaging between agents that may not be continuously online.
     Messages are queued at the destination and delivered when the
     destination is available. See [I-D.sharif-agent-transport-protocol].


     The Agent Trust Transport Protocol (ATTP) provides synchronous agent-
     to-server communication with mandatory signing on every request. ATTP
     introduces the "attp://" URL scheme to mark endpoints that require
     trust-enforced transport. See [I-D.sharif-attp-agent-trust-
     transport].


     Both protocols are complementary to HTTP and coexist with it; they do
     not replace existing transport.


  10.9.  Model Integrity Verification


     Model integrity verification ensures that an AI model file loaded by
     an agent has not been tampered with between publication and use. A
     signed manifest containing file hashes and metadata travels with the
     model and is verified at load time. Supported model formats include
     SafeTensors, PyTorch, GGUF, ONNX, and TensorFlow.


     This mechanism addresses a threat that is specific to ML systems: an
     attacker modifies a model file to introduce a backdoor or bias, and
     the modification is not detected at load time. Without integrity
     verification, the agent acts on a compromised model. With integrity
     verification, the load fails and the agent does not run.


  10.10.  Trust-Gated Networking


     Trust-gated networking is a network enforcement pattern in which
     every outbound connection from an agent is evaluated against a trust
     policy before the connection is permitted. Destinations below a
     minimum trust threshold are blocked at the socket layer, preventing
     agents from contacting untrusted services.


     The mechanism requires a trust score or trust level associated with
     each destination (typically an external service or peer agent) and a
     policy specifying the minimum level required for each type of action.
     Integration with a trust index service (analogous to a URL reputation
     service) provides the destination-side input.


  10.11.  Agent Scope Expression


     Agent scope expression is a format for declaring what an agent may
     do, at finer granularity than OAuth scopes. A scope expression
     specifies the allowed tools or methods, the allowed parameter values
     (e.g., specific counterparties, specific amount ranges), time
     windows, and cumulative usage limits.


     Scope expressions are intended to be verifiable: a decision point can
     take a scope expression and a proposed action and determine in
     bounded time whether the action is within the scope. This rules out
     Turing-complete policy languages for production use; the expression
     language should be expressive enough for common cases but tractable
     to evaluate and analyse.


  10.12.  Agent Revocation


     Agent revocation invalidates a specific agent identity without
     invalidating other identities issued by the same authority or the
     principal's session. Two mechanisms are required.


     Pull-based revocation. Verifiers check a revocation list or status
     endpoint before accepting an action. This is the OCSP model for X.509
     certificates. The limitation is that verifiers must check, and they
     must trust the revocation source.


     Push-based revocation. The issuing authority publishes a signed
     revocation notice to all subscribed verifiers. Verifiers receive and
     cache the notice, and reject subsequent actions by the revoked agent.
     This is more responsive but requires a subscription mechanism.


     In practice, high-assurance deployments use both. A status endpoint
     is consulted for the current revocation list, and push notifications
     are used for rapid propagation of urgent revocations.


  10.13.  Cross-Domain Trust Portability


     Cross-domain trust portability is the ability for an agent's trust
     standing in one domain to be verified in another. An agent with trust
     level L3 in its home organisation should be able to prove that status
     to an external verifier without the external verifier having to re-
     evaluate the entire trust history.


     This mechanism requires:


     * A standard format for portable trust assertions.
     * A mechanism for federated verification (the home organisation
       vouches for the trust level, and a verifier in a foreign domain can
     verify the home organisation's signature).

     * Agreement on what each trust level means across domains.

     Federation is not mandatory; deployments may choose to operate in
     isolation. But for cross-organisational agent commerce, some form of
     portable trust is necessary.


  10.14.  Fine-Grained Consent


     Fine-grained consent allows a principal to grant an agent authority
     for specific actions, not only for broad categories of actions.
     Instead of "access to the user's calendar", consent might be "create
     and modify events in the user's calendar during business hours, not
     involving external participants, up to 10 events per day."


     Fine-grained consent requires a user interface that can express the
     granted authority in terms the user understands, a storage format for
     the granted scope, and a decision point that can evaluate actions
     against the stored scope (see Section mechanism-agent-scope-
     expression).


     Existing OAuth consent flows can be extended to capture fine- grained
     consent, but doing so adds complexity to the user experience. Careful
     interface design is required to keep consent comprehensible while
     capturing enough detail to be useful.


  10.15.  Agent Discovery


     Agent discovery is the process by which one agent finds another to
     invoke. Discovery mechanisms should support finding agents by
     capability ("an agent that can translate documents"), by identity (a
     specific known agent), or by affiliation ("an agent operated by
     organisation X").


     DNS-based discovery using SRV records is a natural starting point and
     aligns with existing Internet infrastructure. A capability registry
     (analogous to an OpenAPI catalogue) provides richer discovery at the
     cost of additional infrastructure.


     This framework does not mandate a single discovery mechanism. It does
     recommend that any discovery mechanism include trust information as a
     first-class result, so that an agent discovering another agent
     immediately has access to the other agent's trust level and can apply
     policy accordingly.


  10.16.  Agent Capability Negotiation


     Agent capability negotiation is the handshake process by which two
     agents establish what they can do together: which protocols they
     support, which cryptographic algorithms, which trust levels, which
     API versions. This is analogous to TLS cipher suite negotiation.


     The negotiation should be signed, bound to the session, and resistant
     to downgrade attacks. A downgrade attack in the agent context would
     persuade one agent that the other supports only a weaker protocol,
     and cause both parties to operate at a lower trust level than
     necessary. Standard mitigations (signed handshake transcripts,
     explicit minimum-level requirements) apply.


  10.17.  Compliance Evidence Export


     Compliance evidence export is the ability to produce, on demand, a
     verifiable bundle of evidence demonstrating compliance with a
     specific regulatory framework. For the EU AI Act [EU-AI-Act],
     relevant articles include Article 12 (record-keeping), Article 13
     (transparency), Article 14 (human oversight), Article 15 (accuracy,
     robustness, cybersecurity), and Article 50 (identification of AI
     systems).


     An evidence export is a structured document that references entries
     in the agent audit trail, groups them by the requirement they
     satisfy, and includes cryptographic evidence that the entries have
     not been tampered with. It is produced for a specific time range and
     can be verified by an auditor using the audit trail root hashes.


  11.  Threat Model


  11.1.  Scope of the Threat Model


     This threat model covers the autonomous agent itself, its interaction
     with services, and the infrastructure that supports agent identity
     and trust. It does not cover the security of underlying LLM training
     data, prompt injection attacks against the LLM as a reasoning system,
     or the operational security of the agent operator's facilities. Those
     are important and related topics, but they are out of scope for this
     document.


     Following the guidance of [RFC3552], the threat model identifies
     assets, threats, attackers, and mitigations, then analyses how the
     mechanisms of this framework address each threat.


  11.2.  System Model and Attack Surface


     The figure below shows the system model assumed by this threat model.
     Arrows denote trust boundaries that an attacker may attempt to cross.
     Each boundary is a candidate attack surface.


        +----------+                          +-------------+
        | Principal|                          | Issuing     |
        | (human)  |<----- (2) issues -------->| Authority  |
        +----------+                          +-------------+
             |                                       |
             | (1) authorises                        | (3) signs
             |                                       | passport
             v                                       v
        +-----------+       (4) runs      +------------------+
        | Agent     |<------------------->|   Agent          |
        | Operator  |                     |   Instance       |
        +-----------+                     +------------------+
                                                  |
                                                  | (5) signs action
                                                  | with private key
                                                  v
                                          +------------------+
                                          |   Action         |
                                          |   (signed)       |
                                          +------------------+
                                                  |
                                                  | (6) submitted
                                                  v
                                          +------------------+
                                          |   Target Service |
                                          |                  |
                                          |  +------------+  |
                                          |  | Trust Gate |  |
                                          |  +------------+  |
                                          |        |         |
                                          |        v         |
                                          |  +------------+  |
                                          |  | Business   |  |
                                          |  | Logic      |  |
                                          |  +------------+  |
                                          |        |         |
                                          |        v         |
                                          |  +------------+  |
                                          |  | Audit      |  |
                                          |  | Trail      |  |
                                          |  +------------+  |
                                          +------------------+
                                                  ^
                                                  |
                                          +------------------+
                                          | External Witness |
                                          | (anchoring,      |
                                          |  transparency)   |
                                          +------------------+

            Figure 7: System Model and Attack Surfaces


     The numbered arrows mark trust boundaries where an attacker can
     attempt a compromise:


     (1) Principal-to-operator: compromise of the principal allows
     unauthorised delegation to agents. (2) Principal-to-authority:
     compromise of the authority- principal binding allows passport
     misissuance. (3) Authority-to-agent: compromise of the passport
     issuance process allows forged or misrouted credentials. (4)
     Operator-to-agent: compromise of the agent runtime allows key
     extraction, code substitution, or behavioural tampering. (5) Agent-
     to-target: compromise of the transport allows message tampering,
     replay, or impersonation. (6) Target-to-witness: compromise of the
     audit anchoring allows retroactive log tampering.


     Each of the threats below maps to one or more of these boundaries.


  11.3.  Assets


     The following assets require protection.


     Agent identity credentials. The private key of an agent's identity
     and the passport issued by the authority. Compromise allows
     impersonation of the agent.


     Audit trails. The sequence of evidence records produced by an agent.
     Modification allows deniability or framing.


     Authorization policies. The rules that determine what an agent may
     do. Modification allows privilege escalation.


     Trust scores. The accumulated behavioural and peer attestations about
     an agent. Manipulation allows unjustified trust elevation or
     unjustified denial of service.


     Model files. The ML model weights and configuration used by the
     agent. Modification allows behavioural manipulation (backdoors,
     biased outputs).


     Delegation chains. The records of authority passed from principal to
     agent to sub-agent. Modification allows unauthorised delegation.


     Action evidence. The bundles that record individual actions.
     Modification or fabrication undermines forensic analysis.


  11.4.  Attackers


     This framework assumes the following attacker capabilities.


     External attacker. An attacker with Internet-level access, capable of
     intercepting unencrypted traffic, initiating connections to public
     endpoints, and executing computationally bounded attacks. This is the
     standard adversary assumed in TLS [RFC8446] and related protocols.


     Malicious server. A server that an agent connects to, which may
     attempt to deceive the agent by returning fabricated responses,
     claiming identities it does not hold, or providing tool definitions
     that differ from the published versions.


     Compromised agent. An agent whose operational security has been
     breached, either through software compromise, key extraction, or
     insider action. A compromised agent can sign arbitrary actions within
     its authority.


     Malicious agent operator. The operator of an agent that is
     adversarial to the verifying party. The operator controls the agent's
     code, keys, and outputs. This is a stronger threat than a compromised
     agent, because the operator has insider access to the agent by
     design.


     Colluding agents. A set of agents, possibly operated by the same or
     cooperating operators, that coordinate to manipulate trust scoring,
     fabricate peer attestations, or launder malicious actions through
     intermediaries.


     Pervasive passive surveillance. A large-scale adversary capable of
     passive monitoring of Internet traffic [RFC7258]. This adversary does
     not inject traffic but observes and correlates flows to learn about
     agents and their principals.


  11.5.  Threats


     The following threats are analysed.


     Agent impersonation. An attacker obtains or forges credentials to
     present themselves as a legitimate agent.


     Replay attack. An attacker captures a signed action by a legitimate
     agent and replays it to the same or another verifier.


     Message tampering. An attacker intercepts a signed action and
     modifies parameters before the action reaches the verifier.


     Passport forgery. An attacker creates a passport that is not issued
     by a legitimate authority but is accepted as legitimate by verifiers.


     Key extraction. An attacker obtains an agent's private key through
     memory disclosure, side channels, or insider action.


     Log tampering. An attacker modifies or deletes entries in an agent's
     audit trail.


     Code substitution. An attacker substitutes a modified version of the
     agent's code for the legitimate version, while the identity
     credentials remain valid.


     Model tampering. An attacker modifies an ML model file loaded by the
     agent, introducing backdoors or biased outputs.


     Delegation abuse. An attacker causes an agent to delegate to an
     unauthorised sub-agent, or escalates privilege through a crafted
     delegation chain.


     Trust manipulation. An attacker inflates an agent's trust score
     through colluding attestations, or deflates a competitor's trust
     score through fabricated negative reports.


     Revocation bypass. An attacker continues to use a revoked identity by
     preventing the verifier from learning about the revocation.


     Policy bypass. An attacker crafts requests that evade the
     authorization policy while still achieving the attacker's goal (for
     example, by chaining multiple permitted actions to produce a
     forbidden outcome).


     Resource exhaustion. An attacker submits large numbers of requests to
     exhaust the verifier's capacity to check signatures, evaluate policy,
     or write audit entries.


     Side-channel leakage. An attacker observes timing, memory, or other
     side channels during signature verification to extract information
     about the verifier or the signing key.


     Downgrade attack. An attacker persuades two parties to negotiate a
     weaker protocol than both support, reducing the security of their
     interaction.


     Cross-domain confusion. An attacker exploits ambiguity in how trust
     levels are interpreted across organisational boundaries to gain
     access they would not have in a single domain.


     Sybil attack. An attacker creates many identities to dilute the
     effect of negative signals or to manipulate trust scoring.


     Principal confusion. An attacker causes an action to be attributed to
     the wrong principal, either by tampering with the delegation chain or
     by exploiting ambiguity in the principal identifier.


  11.6.  STRIDE Analysis


     The threats above are grouped below using the STRIDE taxonomy
     (Spoofing, Tampering, Repudiation, Information disclosure, Denial of
     service, Elevation of privilege). The mechanism column lists the
     primary framework mechanism that mitigates the threat.


        STRIDE    Threat                   Mechanism
        ------    ------                   ---------
        S         Agent impersonation      Cryptographic identity,
                                           passport verification,
                                           per-operation signing
        S         Passport forgery         Issuing authority signature,
                                           trust root verification
        S         Principal confusion      Principal binding in
                                           passport, delegation chain
                                           verification
        S         Sybil attack             Trust levels require
                                           history and attestations;
                                           new identities capped low
        T         Message tampering        Per-operation signing over
                                           canonicalised payload
        T         Log tampering            Hash-chained audit trail,
                                           external anchoring
        T         Code substitution        Code attestation, model
                                           integrity verification
        T         Model tampering          Signed model manifest
                                           verified at load time
        R         Action repudiation       Per-operation signing,
                                           non-repudiable receipts
        R         Delegation repudiation   Signed delegation chain
                                           with bounded depth
        I         Passport content leak    Opaque identifiers,
                                           pseudonymous options
        I         Audit trail leak         Encryption at rest,
                                           hash-only minimal bundles
        I         Trust level leak         Coarse-grained or
                                           ephemeral trust assertions
                                           for cross-domain use
        D         Resource exhaustion      Rate limiting at Trust
                                           Gate, pre-verification
                                           filtering
        D         Trust Gate unavailability Fail-closed default, high
                                           availability design
        D         Audit trail flooding     Quota per agent, eviction
                                           policy, backpressure
        E         Policy bypass            Tractable scope language,
                                           cumulative usage limits
        E         Delegation abuse         Bounded delegation depth,
                                           signed scope inheritance
        E         Revocation bypass        Pull + push revocation,
                                           level-specific check
                                           requirements
        E         Downgrade attack         Signed capability
                                           negotiation, minimum-level
                                           enforcement

                   Figure 8: STRIDE Threat Analysis


  11.7.  Attack Tree for Agent Action Forgery


     The attack tree below shows what an attacker must accomplish to
     successfully cause an unauthorised action to be accepted by a
     verifier. Each leaf is a specific capability the attacker must gain.
     Each interior node is a disjunction (OR) of the paths beneath it,
     unless marked AND.


        Goal: Get unauthorised action accepted by verifier
          |
          +-- OR: Forge agent identity
          |       |
          |       +-- Obtain valid private key
          |       |     |
          |       |     +-- Extract from agent memory
          |       |     +-- Extract from HSM (very hard)
          |       |     +-- Intercept during issuance
          |       |
          |       +-- Forge issuing authority signature
          |       |     |
          |       |     +-- Compromise authority private key
          |       |     +-- Break ECDSA P-256 (very hard)
          |       |
          |       +-- Substitute trust root at verifier
          |             |
          |             +-- Compromise verifier trust store
          |             +-- Social-engineer operator
          |
          +-- OR: Bypass Trust Gate
          |       |
          |       +-- Find policy bug (missing check)
          |       +-- Chain permitted actions to forbidden outcome
          |       +-- Race condition in state check
          |       +-- DoS the Trust Gate (if fail-open)
          |
          +-- OR: Replay valid action
          |       |
          |       +-- Capture signed action in transit
          |       +-- AND: Reuse before nonce expiry
          |                AND: Nonce store failure at verifier
          |
          +-- OR: Exploit delegation
                  |
                  +-- Present stale delegation token
                  +-- Exceed delegation depth silently
                  +-- Principal confusion via ambiguous ID

             Figure 9: Attack Tree for Action Forgery


     The attack tree shows that forging an accepted action requires the
     attacker to successfully complete at least one full path from root to
     leaf. The framework is designed so that each leaf is individually
     expensive or impossible:


     * Extracting private keys from hardware-backed storage is
       computationally and physically expensive.

     * Breaking ECDSA P-256 is computationally infeasible with
       classical computers.

     * Compromising an issuing authority is detectable via
       transparency logs (if used) and attributable.

     * Policy bugs are findable and fixable; cumulative usage
       limits and fail-closed defaults limit blast radius.

     * Replay attacks require defeating both nonce stores and
       timestamp windows simultaneously.

     * Delegation exploits are bounded by the cryptographic chain
       and the depth limit.


     A security argument for the framework is that an attacker must either
     break cryptography, compromise a well-defended root of trust, or find
     an implementation bug. The framework does not guarantee the absence
     of implementation bugs, but it minimises their impact and makes them
     detectable.


  11.8.  How the Framework Addresses These Threats


     Each threat above is addressed by one or more mechanisms in the
     framework. The correspondence is summarised here.


     Agent impersonation is addressed by cryptographic identity and
     signing. An attacker cannot sign actions as a legitimate agent
     without the agent's private key. If the key is properly protected,
     impersonation requires key extraction, which is a separate threat.


     Replay attacks are addressed by per-operation signing, which includes
     a nonce and timestamp in every signature. A verifier rejects
     signatures with nonces it has already seen or timestamps outside an
     acceptance window.


     Message tampering is addressed by per-operation signing. Modification
     of any parameter invalidates the signature.


     Passport forgery is addressed by the issuing authority signature. A
     forged passport that is not signed by a recognised authority is
     rejected.


     Key extraction is addressed by recommending hardware-backed key
     storage for high-assurance deployments. The framework does not
     eliminate key extraction as a threat, but it provides a strict upper
     bound on the damage an extracted key can do: at most, an attacker can
     impersonate the specific agent until the key is revoked.


     Log tampering is addressed by hash-chained audit trails with external
     anchoring. Modification of a past entry is detectable because it
     invalidates the chain. Anchoring to an external witness protects
     against the operator of the audit system rewriting history
     unilaterally.


     Code substitution is addressed by code attestation. A deployment that
     requires code attestation as a precondition for accepting actions
     will reject an agent whose code hash does not match the attested
     value.


     Model tampering is addressed by model integrity verification. An
     agent that verifies its model before loading will refuse to run with
     a tampered model.


     Delegation abuse is addressed by explicit delegation chains with
     bounded depth. An attacker cannot escalate through delegation because
     each link is cryptographically bound and the chain has a policy-
     enforced maximum length.


     Trust manipulation is addressed partially. A trust system cannot be
     made fully resistant to manipulation by colluding participants;
     however, the framework recommends asymmetric trust functions (harder
     to inflate than to lose), peer attestation weighting by attester
     reputation, and detection of anomalous attestation patterns.


     Revocation bypass is addressed by using both pull-based and push-
     based revocation, and by requiring verifiers to check revocation at
     the policy-specified granularity for each trust level. High-trust
     operations (L3, L4) require revocation checks; lower-trust operations
     may skip them to improve latency.


     Policy bypass is addressed by analysis of the scope expression
     language and by cumulative usage limits. The framework recommends
     that scope languages be tractable (not Turing complete) so that
     reachability analysis is possible.


     Resource exhaustion is addressed by rate limiting at the Trust Gate
     and by placing expensive operations (signature verification, policy
     evaluation) behind rate limits at the service boundary.


     Side-channel leakage is addressed by using constant-time signature
     verification implementations. The framework recommends specific
     algorithms (ECDSA over P-256 with constant-time implementations) but
     implementation-specific mitigations are the responsibility of
     deployers.


     Downgrade attacks are addressed by requiring signed capability
     negotiation in handshake protocols. A transcript of the negotiated
     parameters is included in the session key derivation, so that a
     downgrade alters the session key and is detected.


     Cross-domain confusion is addressed by requiring explicit mapping of
     trust levels between domains in any federation agreement, and by
     including the issuing authority identifier in every passport.


     Sybil attacks are addressed partially by the requirement that trust
     requires observable, attested, historical behaviour. Creating many
     new identities does not gain trust, because new identities are capped
     at low levels until they accumulate history.


     Principal confusion is addressed by requiring the principal
     identifier to be cryptographically bound to the agent passport at
     issuance time, and to be verified against the delegation chain by the
     verifier.


  11.9.  Threats Not Addressed


     The framework does not address the following threats and explicitly
     declares them out of scope.


     Prompt injection against the LLM. If an attacker can cause an agent's
     LLM to select an undesired action, the framework will faithfully
     record and authorise that action within the agent's policy envelope.
     The framework does not prevent the LLM from being deceived. It
     ensures that the resulting action is auditable and bounded by the
     pre-agreed policy.


     Compromise of the principal's credentials. If the principal's account
     is compromised, the attacker can issue agents with the full authority
     of the principal. The framework protects the agents but cannot
     protect against a compromised principal.


     Insider attacks by the issuing authority. A malicious issuing
     authority can issue passports to agents it should not, or revoke
     passports it should not. Mitigation requires transparency mechanisms
     (similar to Certificate Transparency [RFC6962]) so that issuing
     authority actions are publicly auditable. The framework recommends
     such transparency but does not mandate a specific transparency
     mechanism.


     Side-channel attacks on the LLM itself. Training data extraction,
     membership inference, and model extraction are machine learning
     research topics that are out of scope.


     Quantum adversaries. All cryptographic recommendations in this
     document are based on classical cryptographic assumptions (elliptic
     curve discrete logarithm). A quantum adversary with sufficient
     resources would undermine these assumptions. Post- quantum migration
     is a separate concern shared with all of Internet security and is out
     of scope here.


  12.  Security Considerations


  12.1.  Cryptographic Choices


     The framework recommends ECDSA over NIST P-256 with SHA-256 for
     signing, per [FIPS186-5]. This choice balances security (128-bit
     level), performance (roughly 50 microseconds for signing on modern
     hardware), compact signatures (64 bytes), and ubiquitous
     implementation support.


     Implementations MUST use constant-time code paths for signature
     verification to prevent timing side-channel attacks. Implementations
     SHOULD use low-S normalisation (BIP-0062) to prevent signature
     malleability. Canonical JSON serialisation [RFC8785] SHOULD be used
     before signing so that verification is deterministic across
     serialisation differences.


     Future versions of this framework may recommend additional or
     alternative algorithms. Implementations SHOULD be designed for
     algorithm agility: the algorithm identifier is carried in the
     signature envelope, and new algorithms can be added without protocol
     changes.


  12.2.  Key Management


     Agent private keys are high-value targets. Key management practice
     has a larger effect on real-world security than algorithm choice.


     Recommendations for key management.


     Keys SHOULD be generated inside the environment that will use them,
     not imported from outside. This minimises the window during which the
     key exists in transferable form.


     Keys SHOULD be stored in hardware-backed storage (HSM, TEE, secure
     enclave, TPM) where available. Where hardware backing is not
     available, keys SHOULD be protected with file permissions, memory
     protection, and careful handling of process memory dumps.


     Keys SHOULD be rotated on a policy-defined schedule. Rotation limits
     the window during which a compromised key can be used. The framework
     does not mandate a specific rotation interval; typical values range
     from days (high assurance) to months (standard).


     Key compromise SHOULD trigger immediate revocation of the affected
     agent identity. The revocation mechanism MUST support rapid
     propagation; high-assurance deployments SHOULD use push-based
     revocation.


  12.3.  Trust Level Calibration


     The numeric trust levels (L0 through L4) are intentionally abstract.
     Deployments that use these levels MUST calibrate them to their
     specific risk tolerance. A trust level that is appropriate for
     internal enterprise agent communication may be inappropriate for
     consumer-facing financial transactions.


     Calibration decisions are policy decisions, not technical decisions.
     The framework provides the vocabulary and the ordering; deployments
     provide the semantics.


  12.4.  Denial of Service


     Per-operation signing is a computational cost. A malicious actor
     submitting large numbers of signature verification requests can
     exhaust verifier resources. Mitigations include rate limiting at the
     Trust Gate, caching of verified passports, rejection of requests with
     obviously invalid signatures before cryptographic verification, and
     scaling of verification infrastructure.


     Trust Gates themselves can be targets of denial of service. A Trust
     Gate that is slow or unavailable blocks legitimate traffic. Trust
     Gate implementations MUST be designed to fail-closed (deny on
     failure) by default, but deployments may configure fail-open
     behaviour for specific non-critical operations.


  12.5.  Interaction with Existing Security Mechanisms


     The framework is designed to compose with existing mechanisms, not
     replace them. TLS still provides transport security. OAuth still
     provides client authorization for the principal. WAFs still block
     malformed traffic. The framework adds an agent- specific layer on top
     of these.


     A common mistake is to assume that an agent identity replaces these
     other mechanisms. It does not. An agent with a valid passport still
     needs TLS to protect its signatures in transit. An agent acting on a
     user's behalf still needs the user's OAuth consent. An agent's
     traffic can still be blocked by a WAF rule that is unrelated to
     identity.


  13.  Privacy Considerations


  13.1.  Attribution and Pseudonymity


     Agent identities can reveal information about the principal. An
     identifier like "payment-bot-alice" allows an observer to infer that
     Alice is using an automated payment system. In contexts where this
     inference is a privacy concern, identifiers SHOULD be opaque (random
     strings rather than descriptive names).


     The framework's recommendation of an "asp_" prefix followed by random
     hexadecimal characters is compatible with opaque identifiers: the
     prefix identifies the format but conveys no information about the
     principal.


  13.2.  Linkability Across Actions


     An agent that signs every action with the same identity creates a
     cryptographic link between those actions. An observer with access to
     the signatures can determine that they were produced by the same
     agent. In some contexts (auditability, compliance) this is desirable.
     In others (user privacy against observers with traffic access) it is
     not.


     Deployments that require unlinkability SHOULD consider techniques
     such as one-time identities (a new passport per action), blind
     signatures, or zero-knowledge proofs. These are research topics with
     limited standardised support; the framework does not mandate a
     specific approach.


  13.3.  Audit Trail Contents


     Audit trails contain detailed records of agent activity. Depending on
     what the agent does, the audit trail may contain sensitive personal
     data, financial information, or confidential business data.
     Protecting the audit trail is not only a security concern but a
     privacy concern.


     Recommendations:


     Audit trails SHOULD be encrypted at rest, with access controls
     limiting who can read them.


     Audit trails SHOULD be retained for a policy-defined period and then
     deleted, in accordance with applicable data protection regulation
     (for example, the General Data Protection Regulation in the European
     Union).


     Audit trails SHOULD NOT include full content of requests or responses
     where hashes would suffice. The minimal evidence bundle described in
     Section evidence-layer contains only hashes, not contents, precisely
     to reduce the privacy surface.


  13.4.  Cross-Organisational Trust Portability


     Cross-domain trust portability (see Section mechanism-trust-
     portability) can leak information. An agent's trust level in one
     organisation reveals something about that organisation's policies
     when presented to another organisation. Deployments SHOULD consider
     whether exposing trust levels across boundaries is compatible with
     their privacy requirements.


     Possible mitigations include coarse-grained trust portability (only
     expose a binary trusted/untrusted decision, not the level), ephemeral
     trust assertions (valid only for a single verifier for a short time),
     and selective disclosure (expose only the minimum information
     needed).


  14.  Integration with Existing Standards


  14.1.  OAuth 2.0 and OpenID Connect


     The framework is designed to extend OAuth 2.0 [RFC6749] and OpenID
     Connect, not to replace them. An agent passport can be carried as an
     extension claim in an OIDC ID Token or in a JWT access token. The
     agent's actions can be signed with a key that is distinct from the
     OAuth client credentials but referenced from the OAuth token.


     Specifically, an agent identity can be integrated with OAuth as
     follows. The principal authenticates to an OAuth authorization server
     and grants authority to a client (the agent runtime). The
     authorization server issues an access token as normal. The agent
     runtime then issues an agent passport from its own internal issuing
     authority (or from an external issuing authority) and presents both
     the OAuth token and the passport to the target service. The target
     service verifies the OAuth token (the principal's authorization) and
     the passport (the agent's identity) independently.


     This composition preserves the separation of concerns: OAuth handles
     authorization, the framework handles agent identity and trust.
     Neither replaces the other.


  14.2.  FAPI 2.0


     FAPI 2.0 [FAPI2] defines a security profile for high-assurance APIs
     (banking, government, healthcare). FAPI 2.0 provides sender-
     constrained tokens, strong client authentication, and protection
     against a specific set of attacks.


     FAPI 2.0's current profile is human-centric. The sender constraint
     binds the token to a client, not to an agent instance. The framework
     described in this document complements FAPI 2.0 by adding agent
     identity at the instance granularity and per-operation signing on top
     of FAPI's session-level guarantees.


     A deployment that uses FAPI 2.0 for high-assurance API access and
     this framework for agent identity can satisfy both the session-level
     guarantees FAPI provides and the per-action agent-level guarantees
     the framework provides. The combination is additive.


  14.3.  mTLS and Sender-Constrained Tokens


     Mutual TLS [RFC8705] provides a strong binding between a client
     certificate and the requests made over a TLS session. Sender-
     constrained tokens bind an access token to the mTLS certificate of
     the client.


     These mechanisms operate at the transport layer and bind to a
     specific TLS endpoint. An agent's identity needs to bind to the
     specific agent instance, which may share a TLS endpoint with other
     agents. The framework's per-operation signing provides this finer
     granularity while still allowing mTLS to secure the overall
     transport.


  14.4.  Certificate Transparency


     Certificate Transparency [RFC6962] provides public, append- only logs
     of TLS certificate issuance. The goal is to detect misissuance by
     certificate authorities. The same construction applies to agent
     passports: public transparency logs of passport issuance allow
     detection of malicious or compromised issuing authorities.


     A transparency mechanism for agent passports is compatible with the
     framework and is recommended for high-assurance deployments.
     Specification is out of scope for this document but is identified as
     a topic for future work.


  14.5.  OWASP AI and MCP Security Guidance


     OWASP has published security guidance for AI and for the Model
     Context Protocol, including the OWASP MCP Security Cheat Sheet
     [OWASP-MCP]. The guidance covers specific controls (input validation,
     resource limits, authentication, logging) that deployments should
     implement.


     The framework in this document is complementary to OWASP guidance.
     OWASP describes what to do; the framework describes how to structure
     the system so that those controls compose coherently. A deployment
     that follows OWASP guidance and uses the framework has both the
     specific controls and the structural model.


  14.6.  NIST AI Risk Management Framework


     The NIST AI RMF [NIST-AI-RMF] provides a risk management framework
     for AI systems. It defines functions (Govern, Map, Measure, Manage)
     and outcomes for responsible AI development.


     This framework is more narrow in scope than the NIST AI RMF but
     complements it. The NIST AI RMF's outcomes for logging, transparency,
     and accountability are supported by the evidence layer and audit
     trail mechanisms described here. A deployment that uses this
     framework to implement the technical primitives can satisfy many of
     the technical requirements implied by the NIST AI RMF's "Manage"
     function.


  14.7.  EU AI Act


     The EU AI Act [EU-AI-Act] imposes specific requirements on providers
     and deployers of AI systems. The relevant articles include Article 12
     (record keeping), Article 13 (transparency), Article 14 (human
     oversight), Article 15 (accuracy, robustness, and cybersecurity), and
     Article 50 (identification of AI systems).


     The framework's mechanisms map to these requirements as follows.


     Article 12 (record keeping) is supported by the agent audit trail
     mechanism. The hash-chained, tamper-evident log with external
     anchoring provides the record-keeping foundation.


     Article 13 (transparency) is supported by agent identity and
     attestation. Users and auditors can determine which agent took which
     action.


     Article 14 (human oversight) is supported by the Trust Gate
     mechanism, which provides a decision point at which human policy
     (expressed in rules) can be enforced.


     Article 15 (accuracy, robustness, cybersecurity) is supported by per-
     operation signing (integrity), model integrity verification
     (robustness of the underlying model), and trust-gated networking
     (cybersecurity of outbound connections).


     Article 50 (identification) is supported by agent identity
     credentials. Each agent has a verifiable identity that can be
     presented to users or auditors.


     Compliance evidence export (see Section mechanism-compliance-
     evidence-export) produces structured artifacts that map directly to
     these requirements for regulatory inspection.


  15.  IANA Considerations


     This document does not request IANA action. Specific mechanisms
     referenced in this document may request IANA actions in their
     respective specifications.


  1.  Acknowledgements


     The author thanks contributors and reviewers in the OWASP Foundation,
     the CIS Benchmarks working group, the IETF community, and the open-
     source ecosystem around the Model Context Protocol for discussions
     that shaped this framework.


  2.  Author Credentials


     Raza Sharif is the Founder and Lead AI Architect of CyberSecAI Ltd.
     He is a Fellow of the British Computer Society (FBCS), a Certified
     Information Systems Security Professional (CISSP), and a Certified
     Secure Software Lifecycle Professional (CSSLP). He is a contributor
     to the OWASP MCP Security Cheat Sheet, an invited contributor to the
     CIS MCP Benchmark working group, and the author of multiple IETF
     Internet-Drafts on autonomous agent identity, transport, payment
     trust, and audit trail.


  3.  Relation to Existing Internet-Drafts


     This framework references and is supported by the following Internet-
     Drafts, each of which specifies a particular mechanism in more
     detail.


     * draft-sharif-mcps-secure-mcp: MCPS specification for MCP
       security.


     * draft-sharif-openid-agent-identity: OpenID Connect claims for
       agent identity.


     * draft-sharif-agent-payment-trust: Protocol for trust-aware
       agent-initiated payments.


     * draft-sharif-agent-audit-trail: Format and rules for the
       agent audit trail.


     * draft-sharif-agent-transport-protocol: Asynchronous agent
       messaging.


     * draft-sharif-attp-agent-trust-transport: Synchronous agent-to-
       server transport with mandatory signing.


     These drafts are individual submissions by the same author and may be
     adopted, merged, or revised as this framework matures.


  4.  Document History


     draft-sharif-agent-identity-framework-00: Initial submission.




  Authors' Addresses


     Raza Sharif (FBCS, CISSP, CSSLP)
     CyberSecAI Ltd
     London
     United Kingdom

     Email: contact@agentsign.dev
     URI:   https://cybersecai.co.uk


name: draft-sharif-apki-agent-pki
rev: 00
time: 2026-04-10T19:26:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-12T19:26:20Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698321+00:00
source: ietf
title:
  Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents

abstract:
  Autonomous artificial intelligence (AI) agents are increasingly
     performing actions on the Internet that require verifiable identity:
     financial transactions, regulated data access, tool invocations,
     and inter-agent coordination.  Traditional Public Key Infrastructure
     (PKI) based on X.509 certificates was designed for human-operated
     clients and long-lived servers.  It lacks primitives for graduated
     trust scoring, capability constraints, delegation chains, model
     provenance, and the ephemeral lifecycles characteristic of AI
     agents.

     This document defines Agent Public Key Infrastructure (APKI), a
     certificate-based identity and trust system for autonomous AI
     agents.  APKI extends X.509v3 with five agent-specific extensions,
     defines the agent:// URI scheme for agent identification, specifies
     Agent Transparency Logs modelled on Certificate Transparency
     (RFC 9162), and provides mechanisms for cross-organizational trust
     federation.  APKI is designed to be compatible with existing PKI
     deployments, SPIFFE workload identity, and the IETF WIMSE working
     group's specifications.

full_text:
  Internet Engineering Task Force                                R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Standards Track                         April 10, 2026
  Expires: October 10, 2026


        Agent Public Key Infrastructure (APKI): Certificate-Based
                Identity and Trust for Autonomous AI Agents
                      draft-sharif-apki-agent-pki-00


  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 October 10, 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.

  Abstract

     Autonomous artificial intelligence (AI) agents are increasingly
     performing actions on the Internet that require verifiable identity:
     financial transactions, regulated data access, tool invocations,
     and inter-agent coordination.  Traditional Public Key Infrastructure
     (PKI) based on X.509 certificates was designed for human-operated
     clients and long-lived servers.  It lacks primitives for graduated
     trust scoring, capability constraints, delegation chains, model
     provenance, and the ephemeral lifecycles characteristic of AI
     agents.

     This document defines Agent Public Key Infrastructure (APKI), a
     certificate-based identity and trust system for autonomous AI
     agents.  APKI extends X.509v3 with five agent-specific extensions,
     defines the agent:// URI scheme for agent identification, specifies
     Agent Transparency Logs modelled on Certificate Transparency
     (RFC 9162), and provides mechanisms for cross-organizational trust
     federation.  APKI is designed to be compatible with existing PKI
     deployments, SPIFFE workload identity, and the IETF WIMSE working
     group's specifications.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  The Agent Identity Problem  . . . . . . . . . . . . . .  3
       1.2.  Why Traditional PKI Is Insufficient . . . . . . . . . .  4
       1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . .  5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . .  7
       3.1.  Component Hierarchy . . . . . . . . . . . . . . . . . .  7
       3.2.  Trust Model . . . . . . . . . . . . . . . . . . . . . .  8
     4.  Agent URI Scheme  . . . . . . . . . . . . . . . . . . . . .  9
       4.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  9
       4.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.  Placement in X.509 Certificates . . . . . . . . . . . . 10
     5.  Agent Certificate Profile . . . . . . . . . . . . . . . . . 10
       5.1.  Base Certificate Fields . . . . . . . . . . . . . . . . 10
       5.2.  AgentTrustScore Extension . . . . . . . . . . . . . . . 11
       5.3.  AgentCapabilities Extension . . . . . . . . . . . . . . 12
       5.4.  AgentDelegation Extension . . . . . . . . . . . . . . . 13
       5.5.  AgentProvenance Extension . . . . . . . . . . . . . . . 14
       5.6.  AgentBehaviouralAttestation Extension . . . . . . . . . 15
     6.  Trust Score Semantics . . . . . . . . . . . . . . . . . . . 16
       6.1.  Trust Tiers . . . . . . . . . . . . . . . . . . . . . . 16
       6.2.  Trust Decay . . . . . . . . . . . . . . . . . . . . . . 17
       6.3.  Trust Updates . . . . . . . . . . . . . . . . . . . . . 17
       6.4.  Re-issuance Triggers  . . . . . . . . . . . . . . . . . 18
     7.  Agent Certificate Lifecycle . . . . . . . . . . . . . . . . 18
       7.1.  Enrollment  . . . . . . . . . . . . . . . . . . . . . . 18
       7.2.  Issuance  . . . . . . . . . . . . . . . . . . . . . . . 19
       7.3.  Renewal . . . . . . . . . . . . . . . . . . . . . . . . 19
       7.4.  Revocation  . . . . . . . . . . . . . . . . . . . . . . 20
     8.  Agent Transparency Logs . . . . . . . . . . . . . . . . . . 20
       8.1.  Log Structure . . . . . . . . . . . . . . . . . . . . . 21
       8.2.  Signed Agent Timestamps . . . . . . . . . . . . . . . . 21
       8.3.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . 22
     9.  Delegation Chains . . . . . . . . . . . . . . . . . . . . . 22
       9.1.  Monotonic Attenuation Invariant . . . . . . . . . . . . 22
       9.2.  Delegation Issuance . . . . . . . . . . . . . . . . . . 23
       9.3.  Cascade Revocation  . . . . . . . . . . . . . . . . . . 23
     10. Federation  . . . . . . . . . . . . . . . . . . . . . . . . 24
       10.1. Trust Bundle Exchange . . . . . . . . . . . . . . . . . 24
       10.2. Federation Verification . . . . . . . . . . . . . . . . 24
       10.3. Trust Score Mapping . . . . . . . . . . . . . . . . . . 25
     11. Security Considerations . . . . . . . . . . . . . . . . . . 25
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . 28
       13.1. Normative References  . . . . . . . . . . . . . . . . . 28
       13.2. Informative References  . . . . . . . . . . . . . . . . 29
     Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . 30
     Appendix B.  Example Agent Certificate  . . . . . . . . . . . . 33
     Appendix C.  Comparison with Existing Systems . . . . . . . . . 35
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 36


  1.  Introduction

  1.1.  The Agent Identity Problem

     Large language models (LLMs) and related machine learning systems
     have enabled the deployment of autonomous software agents that
     operate with minimal human supervision.  These agents initiate
     financial transactions, query regulated databases, invoke external
     tools via protocols such as the Model Context Protocol (MCP), and
     coordinate with other agents in multi-agent workflows.

     As of early 2026, the MCP ecosystem alone comprises over 97 million
     SDK downloads and 13,000 registered servers.  According to the HID
     Global PKI Survey (March 2026), 16% of enterprises are already
     issuing digital certificates to AI agents, and 34% cite AI agent
     certificates as a top PKI trend.

     Despite this rapid adoption, no standard exists for agent-specific
     certificate-based identity.  Agents currently authenticate using
     mechanisms designed for human users (OAuth 2.0 bearer tokens, API
     keys) or generic workloads (SPIFFE SVIDs).  These mechanisms lack
     the semantics required for agent trust decisions: graduated trust
     levels, capability constraints, delegation chains, and model
     provenance.

     This document defines Agent Public Key Infrastructure (APKI), a
     certificate-based system that provides verifiable identity and
     graduated trust for autonomous AI agents.


  1.2.  Why Traditional PKI Is Insufficient

     Traditional PKI based on X.509 certificates [RFC5280] exhibits
     the following deficiencies when applied to AI agents:

     Temporal Mismatch:  X.509 certificates have validity periods of
        days to years.  AI agents may be created, execute a task, and
        terminate within milliseconds.  Long-lived certificates create
        unnecessarily wide vulnerability windows for ephemeral entities.

     Binary Trust:  A certificate is either valid or revoked.  Agents
        require graduated trust: a newly created agent from an unknown
        provider should receive lower trust than an established agent
        with a verified track record.

     No Capabilities:  Certificates assert identity but do not constrain
        actions.  Agents need capabilities bound to their identity: which
        tools they may invoke, what spend limits apply, what data they
        may access.

     No Delegation:  When a human delegates authority to an agent that
        spawns sub-agents, X.509 provides no mechanism to represent this
        delegation chain with capability attenuation.

     No Provenance:  Certificates do not attest which AI model executes
        within an agent, what version it runs, or what framework hosts
        it.

     Revocation Latency:  CRLs refresh on hourly or daily intervals.
        For agents executing thousands of actions per minute, revocation
        latency measured in hours is unacceptable.

     No Transparency:  Certificate Transparency [RFC9162] covers TLS
        certificates but no equivalent exists for agent identity.


  1.3.  Design Goals

     APKI is designed with the following goals:

     1.  Graduated trust embedded in certificates, not external systems

     2.  Short-lived certificates (minutes, not years) as the default

     3.  Capability constraints bound to agent identity

     4.  Cryptographic delegation chains with monotonic attenuation

     5.  Transparency logs for agent certificate issuance

     6.  Compatibility with existing PKI, SPIFFE, and WIMSE

     7.  Post-quantum algorithm readiness

     8.  Sub-second revocation capability


  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.

     Agent:  An autonomous software entity, typically powered by a
        language model, that performs actions on the Internet with
        minimal human supervision.

     Agent Certificate:  An X.509v3 digital certificate issued to an
        agent, containing the agent's public key, an agent URI in the
        Subject Alternative Name, and one or more APKI-specific
        extensions.

     Agent CA:  A Certificate Authority within the APKI hierarchy that
        issues Agent Certificates.  An Agent CA is typically an
        Organizational Intermediate CA.

     Agent Root CA:  The trust anchor of an APKI deployment.  Operates
        offline and issues certificates only to Organizational
        Intermediate CAs.

     Agent URI:  A Uniform Resource Identifier following the agent://
        scheme that uniquely identifies an agent within a trust domain.

     Trust Score:  A numerical value between 0 and 100 inclusive that
        represents an agent's current trust level.  Embedded in the
        AgentTrustScore certificate extension.

     Trust Tier:  A classification derived from the trust score:
        UNTRUSTED (0-19), RESTRICTED (20-39), STANDARD (40-59),
        ELEVATED (60-79), FULL (80-100).

     Trust Decay:  The mechanism by which an agent's trust score
        decreases over time in the absence of positive behavioural
        signals.

     Capability Constraint:  A binding between an agent's identity and
        specific permitted operations, including tool URIs, spend limits,
        rate limits, and scope descriptors.

     Delegation Chain:  A cryptographically linked sequence of agent
        certificates representing authority delegation from a human
        principal through one or more agents.

     Monotonic Attenuation:  The invariant that each delegation in a
        chain MUST narrow (never expand) the delegated capabilities.

     Agent Transparency Log:  An append-only Merkle hash tree that
        records agent certificate issuance, enabling monitoring for
        unauthorized agent registrations.

     Signed Agent Timestamp (SAT):  A signed data structure returned
        by an Agent Transparency Log upon certificate submission,
        analogous to the Signed Certificate Timestamp (SCT) in
        Certificate Transparency.

     Behavioural Attestation:  Evidence that an agent's declared
        capabilities have been verified by a specified method.

     Model Provenance:  Information about the AI model powering an
        agent, including model family, version, and hosting framework.

     Federation:  The mechanism by which organizations exchange trust
        bundles to enable cross-organizational agent interactions.

     Trust Bundle:  A set of CA certificates representing the trust
        anchors for an APKI trust domain, distributed for federation.


  3.  Architecture Overview

  3.1.  Component Hierarchy

     The APKI system comprises the following components:

         +------------------+
         |  Agent Root CA   |  (offline, air-gapped, HSM-protected)
         +--------+---------+
                  |
         +--------v---------+     +--------v---------+
         |   Org CA Alpha   |     |   Org CA Beta    |
         +--------+---------+     +--------+---------+
                  |                         |
         +--------v---------+     +--------v---------+
         | Agent Cert a1    |     | Agent Cert b1    |
         | Agent Cert a2    |     | Agent Cert b2    |
         | Agent Cert a3    |     | Agent Cert b3    |
         +------------------+     +------------------+

         +------------------+     +------------------+
         | Transparency     |     | Federation       |
         | Log 1            |     | Service          |
         | Log 2            |     | (trust bundles)  |
         +------------------+     +------------------+

     Agent Root CA:  The trust anchor for the entire hierarchy.  It
        operates offline with private key material in a Hardware
        Security Module (HSM).  Issues certificates only to
        Organizational Intermediate CAs.  Validity period: 10-20
        years.

     Organizational Intermediate CA:  Each organization operating AI
        agents deploys one or more Intermediate CAs.  These are online,
        automated systems that issue short-lived agent certificates.
        Validity period: 1-5 years.

     Agent End-Entity Certificates:  Short-lived certificates issued
        to individual agents.  Default validity: 1 hour.  Configurable
        range: 5 minutes to 24 hours.

     Agent Transparency Logs:  Independent append-only Merkle trees
        recording agent certificate issuance.

     Federation Service:  Distributes and consumes trust bundles for
        cross-organizational agent interactions.


  3.2.  Trust Model

     APKI replaces the binary valid/revoked trust model of traditional
     PKI with a graduated trust model:

     1.  Every agent certificate contains a trust score (0-100)

     2.  Trust scores decay over time without positive signals

     3.  Relying parties enforce minimum trust score thresholds

     4.  Certificate re-issuance occurs when scores change materially

     5.  Trust decay serves as soft revocation -- agents that cease
         positive operations gradually lose access

     This model is analogous to a credit score for financial
     transactions: the score reflects accumulated evidence about the
     agent's trustworthiness, not merely the validity of a credential.


  4.  Agent URI Scheme

  4.1.  Syntax

     The agent URI scheme identifies agents within APKI certificates:

         agent-uri = "agent://" trust-domain "/" org "/" type "/" instance

         trust-domain = dns-name
         org          = 1*( ALPHA / DIGIT / "-" / "_" )
         type         = 1*( ALPHA / DIGIT / "-" / "_" )
         instance     = 1*( ALPHA / DIGIT / "-" / "_" )

     The trust-domain component MUST be a valid DNS name identifying
     the organizational trust boundary.  The org component identifies
     the operating entity.  The type component identifies the agent's
     functional classification.  The instance component uniquely
     identifies the specific agent instance.


  4.2.  Examples

         agent://cybersecai.co.uk/payments/payment-bot/a1b2c3d4
         agent://bank.example.com/kyc/verification-agent/e5f6g7h8
         agent://cloud.example.org/data/pipeline-agent/i9j0k1l2


  4.3.  Placement in X.509 Certificates

     The agent URI MUST be placed in the X.509 Subject Alternative
     Name (SAN) extension as a uniformResourceIdentifier, as defined
     in Section 4.2.1.6 of [RFC5280].  This follows the same pattern
     established by SPIFFE for workload identity (spiffe:// URIs in
     SANs).

     Implementations MUST support agent:// URIs in the SAN.
     Implementations SHOULD also support spiffe:// URIs in the same
     certificate for environments that use both APKI and SPIFFE.


  5.  Agent Certificate Profile

  5.1.  Base Certificate Fields

     An APKI agent certificate is a standard X.509v3 certificate
     [RFC5280] with the following field requirements:

     Version:  MUST be v3 (value 2).

     Serial Number:  MUST be a unique positive integer assigned by the
        issuing CA, as per [RFC5280] Section 4.1.2.2.

     Signature Algorithm:  MUST be one of: ecdsa-with-SHA256 (for
        P-256 keys), Ed25519, or ML-DSA-65 (when post-quantum profiles
        are standardized).

     Issuer:  The distinguished name of the Organizational Intermediate
        CA.

     Validity:  The notBefore and notAfter fields.  The validity period
        SHOULD be between 5 minutes and 24 hours.  The RECOMMENDED
        default is 1 hour.

     Subject:  MAY be empty.  Agent identity is carried in the SAN.

     Subject Public Key Info:  The agent's public key.  MUST be one of:
        EC P-256, Ed25519, or ML-DSA-65.

     Extensions:  MUST include SubjectAlternativeName with the agent
        URI.  MUST include at least one APKI extension.  SHOULD include
        all five APKI extensions for maximum interoperability.


  5.2.  AgentTrustScore Extension

     The AgentTrustScore extension embeds a graduated trust score
     within the certificate.

     OID:  id-pe-agentTrustScore (TBD)

     Criticality:  MUST be marked non-critical.

     ASN.1 Definition:

         AgentTrustScore ::= SEQUENCE {
             score               INTEGER (0..100),
             trustTier           ENUMERATED {
                 untrusted           (0),
                 restricted          (1),
                 standard            (2),
                 elevated            (3),
                 full                (4)
             },
             decayRate           INTEGER (0..100),
             lastUpdated         GeneralizedTime,
             computationMethod   UTF8String OPTIONAL
         }

     The score field contains the agent's current trust score.  The
     trustTier field contains the tier classification derived from the
     score.  The decayRate field specifies the number of trust points
     lost per hour in the absence of positive signals.  The
     lastUpdated field records when the score was last computed.  The
     computationMethod field optionally identifies the scoring
     algorithm.

     Relying parties MUST verify that the trust score meets their
     minimum threshold before granting access.  A relying party
     requiring ELEVATED trust MUST reject certificates with scores
     below 60.


  5.3.  AgentCapabilities Extension

     The AgentCapabilities extension binds specific operational
     capabilities to the agent's identity.

     OID:  id-pe-agentCapabilities (TBD)

     Criticality:  SHOULD be marked non-critical.

     ASN.1 Definition:

         AgentCapabilities ::= SEQUENCE {
             capabilities  SEQUENCE OF Capability
         }

         Capability ::= SEQUENCE {
             toolUri       IA5String,
             scope         UTF8String,
             spendLimit    SpendConstraint OPTIONAL,
             rateLimit     RateConstraint OPTIONAL
         }

         SpendConstraint ::= SEQUENCE {
             maxPerTransaction  INTEGER OPTIONAL,
             maxPerPeriod       INTEGER OPTIONAL,
             periodSeconds      INTEGER OPTIONAL,
             currency           PrintableString
         }

         RateConstraint ::= SEQUENCE {
             maxRequests    INTEGER,
             periodSeconds  INTEGER
         }

     The toolUri field identifies a permitted tool or API endpoint.
     The scope field describes the operational scope.  The spendLimit
     field constrains monetary operations.  Monetary values are
     expressed in minor currency units (e.g., pence, cents).  The
     rateLimit field constrains invocation frequency.


  5.4.  AgentDelegation Extension

     The AgentDelegation extension encodes the delegation chain from
     a human principal through one or more agents.

     OID:  id-pe-agentDelegation (TBD)

     Criticality:  SHOULD be marked non-critical.

     ASN.1 Definition:

         AgentDelegation ::= SEQUENCE {
             parentCertHash      OCTET STRING (SIZE(32)),
             delegationDepth     INTEGER (0..255),
             maxDelegationDepth  INTEGER (0..255),
             attenuationRules    AttenuationRules,
             humanPrincipal      UTF8String OPTIONAL
         }

         AttenuationRules ::= SEQUENCE {
             capabilitiesSubset  BOOLEAN DEFAULT TRUE,
             maxTrustScore       INTEGER (0..100) OPTIONAL,
             maxSpendLimit       INTEGER OPTIONAL,
             scopeNarrowing      UTF8String OPTIONAL
         }

     The parentCertHash field MUST contain the SHA-256 hash of the
     parent agent's DER-encoded certificate, creating a cryptographic
     binding.  The delegationDepth field records the current position
     in the chain (0 for agents directly delegated by humans).  The
     maxDelegationDepth field sets the upper bound.  The RECOMMENDED
     maximum delegation depth is 5.

     The fundamental invariant is monotonic attenuation: a child
     agent's capabilities MUST be a strict subset of its parent's
     capabilities.  The issuing CA MUST enforce this invariant at
     certificate issuance time.  A child agent MUST NOT have a higher
     trust score, greater spend limit, or broader scope than its
     parent.


  5.5.  AgentProvenance Extension

     The AgentProvenance extension attests the computational provenance
     of the agent.

     OID:  id-pe-agentProvenance (TBD)

     Criticality:  MUST be marked non-critical.

     ASN.1 Definition:

         AgentProvenance ::= SEQUENCE {
             modelFamily     UTF8String,
             modelVersion    UTF8String,
             framework       UTF8String,
             organizationId  UTF8String,
             buildHash       OCTET STRING (SIZE(32)) OPTIONAL,
             attestEvidence  OCTET STRING OPTIONAL
         }

     The modelFamily field identifies the AI model family (e.g.,
     "claude", "gpt", "gemini").  The modelVersion field identifies
     the specific version.  The framework field identifies the hosting
     framework (e.g., "langchain", "crewai", "mcp-sdk").  The
     organizationId field identifies the operating organization.  The
     buildHash field optionally contains the SHA-256 hash of the
     agent's source code or binary.


  5.6.  AgentBehaviouralAttestation Extension

     The AgentBehaviouralAttestation extension links declared
     capabilities to verifiable attestation evidence.

     OID:  id-pe-agentBehaviouralAttestation (TBD)

     Criticality:  MUST be marked non-critical.

     ASN.1 Definition:

         AgentBehaviouralAttestation ::= SEQUENCE {
             declaredCapabilitiesHash  OCTET STRING (SIZE(32)),
             attestationMethod         ENUMERATED {
                 selfDeclared    (0),
                 caVerified      (1),
                 thirdParty      (2),
                 hardwareBound   (3)
             },
             attestorIdentity  UTF8String OPTIONAL,
             attestationTime   GeneralizedTime,
             evidenceUri       IA5String OPTIONAL
         }

     Attestation methods provide increasing levels of assurance:
     self-declared provides minimal assurance; CA-verified indicates
     the issuing CA tested the agent; third-party indicates an
     independent auditor verified capabilities; hardware-bound
     indicates capabilities are enforced by a trusted execution
     environment.


  6.  Trust Score Semantics

  6.1.  Trust Tiers

     Trust scores map to five tiers:

         +-------+-----------+----------------------------------+
         | Score | Tier      | Access Level                     |
         +-------+-----------+----------------------------------+
         | 0-19  | UNTRUSTED | No access                        |
         | 20-39 | RESTRICTED| Read-only, sandboxed             |
         | 40-59 | STANDARD  | Normal operations within scope   |
         | 60-79 | ELEVATED  | Sensitive operations, regulated  |
         | 80-100| FULL      | Financial, production, audited   |
         +-------+-----------+----------------------------------+

     Relying parties MUST define their minimum required trust tier.
     An agent certificate with a trust score below the minimum MUST
     be rejected.


  6.2.  Trust Decay

     Trust scores decay over time without positive behavioural signals.
     The decay rate is specified in the AgentTrustScore extension as
     points lost per hour.

     The decay formula is:

         current_score = max(0, last_score - (decay_rate * hours_elapsed))

     Where hours_elapsed is calculated from the lastUpdated timestamp
     in the AgentTrustScore extension to the current time.

     A typical decay rate of 2 points per hour means an agent with
     an initial score of 80 reaches STANDARD threshold (60) after 10
     hours and RESTRICTED threshold (40) after 20 hours without
     positive interaction.

     Relying parties SHOULD compute the decayed score when evaluating
     certificates, not rely solely on the score at issuance time.


  6.3.  Trust Updates

     Relying parties report agent behaviour to the Trust Score
     Computation Engine at the issuing CA:

         Successful operation:     +0.5 to +2 points
         Failed operation:         -1 to -5 points
         Policy violation:         -10 to -25 points
         Anomalous behaviour:      -5 to -20 points
         Security incident:        immediate reset to 0

     The reporting protocol is out of scope for this document and
     will be defined in a companion specification.


  6.4.  Re-issuance Triggers

     When the trust score changes by more than a configurable
     threshold (RECOMMENDED default: 10 points), the CA SHOULD issue
     a replacement certificate with the updated score.  The previous
     certificate remains valid until natural expiry.

     When the trust score falls below a configurable minimum
     (RECOMMENDED default: 20), the CA SHOULD revoke the certificate.


  7.  Agent Certificate Lifecycle

  7.1.  Enrollment

     Agent enrollment follows an ACME-like [RFC8555] pattern adapted
     for attestation-based validation:

     1.  The agent generates an ECDSA P-256 or Ed25519 key pair.

     2.  The agent constructs a Certificate Signing Request (CSR)
         per [RFC2986] containing the desired agent URI and
         attestation evidence (model provenance, framework identity,
         organizational binding).

     3.  The agent submits the CSR to its Organizational CA via a
         TLS-protected channel.

     4.  The CA verifies attestation evidence against its policies.

     5.  The Trust Score Computation Engine calculates the initial
         score based on: attestation strength (0-30 points),
         organization reputation (0-20 points), model provenance
         (0-15 points), code attestation (0-15 points), and
         historical data (0-20 points).

     6.  The CA constructs the X.509v3 certificate with APKI
         extensions populated.

     7.  The CA submits the certificate to at least one Agent
         Transparency Log.

     8.  The log returns a Signed Agent Timestamp (SAT).

     9.  The SAT is embedded in the certificate and delivered to
         the agent.


  7.2.  Issuance

     The CA MUST verify the following before issuance:

     1.  The agent URI trust-domain matches the CA's authority

     2.  Attestation evidence is valid per the CA's policies

     3.  If a delegation extension is present, the parent certificate
         is valid and the monotonic attenuation invariant holds

     4.  The certificate has been submitted to at least one
         Transparency Log and a valid SAT has been received


  7.3.  Renewal

     Automated renewal SHOULD occur at 50% of the validity period.
     At renewal:

     1.  The agent presents its current certificate and fresh
         attestation evidence

     2.  The CA recalculates the trust score incorporating all
         behavioural signals received since last issuance

     3.  A new certificate is issued with the updated trust score

     4.  The new certificate is submitted to Transparency Logs


  7.4.  Revocation

     APKI provides three complementary revocation mechanisms:

     Natural Expiry:  Agent certificates have short validity periods
        (default 1 hour).  A compromised certificate expires naturally,
        limiting exposure.  This is the primary mechanism.

     Certificate Revocation Lists:  The CA publishes CRLs with a
        refresh interval of 60 seconds or less.  CRLs include
        cascade-revoked certificates from delegation chains.

     OCSP:  The CA provides OCSP responders with sub-second response
        times.  OCSP stapling is supported.

     Trust Decay:  Serves as soft revocation.  An agent that ceases
        operations sees its score decay below thresholds, losing access
        without explicit revocation.


  8.  Agent Transparency Logs

  8.1.  Log Structure

     Agent Transparency Logs are append-only Merkle hash trees
     following the architecture of Certificate Transparency [RFC9162]
     applied to agent certificates.

     Each leaf in the Merkle tree is the SHA-256 hash of a submitted
     agent certificate (DER-encoded).  The log operator periodically
     signs the tree head (Signed Tree Head, STH), enabling clients to
     verify log consistency and completeness.

     Log operators MUST be independent of the CA hierarchy.  Multiple
     independent logs SHOULD be operated to prevent single points of
     trust.


  8.2.  Signed Agent Timestamps

     When a CA submits a certificate to a log, the log returns a
     Signed Agent Timestamp (SAT) comprising:

         SAT ::= SEQUENCE {
             version        INTEGER,
             logId          OCTET STRING (SIZE(32)),
             timestamp      INTEGER,
             certHash       OCTET STRING (SIZE(32)),
             signature      OCTET STRING
         }

     The logId is the SHA-256 hash of the log's public key.  The
     timestamp is milliseconds since the Unix epoch.  The certHash
     is the SHA-256 hash of the submitted certificate.  The signature
     is computed over all preceding fields using the log's private
     key.

     CAs MUST embed at least one SAT in the issued certificate via
     a SCTList-like extension, analogous to [RFC6962] Section 3.3.


  8.3.  Monitoring

     Organizations SHOULD monitor Agent Transparency Logs for:

     1.  Certificates issued within their trust domain without
         authorization

     2.  Agents claiming organizational affiliation without proper
         delegation

     3.  Anomalous patterns such as bulk registration from unknown CAs

     4.  Agents with trust scores exceeding organizational policy


  9.  Delegation Chains

  9.1.  Monotonic Attenuation Invariant

     The fundamental invariant of APKI delegation is monotonic
     attenuation: at each level of delegation, the child agent's
     authority MUST NOT exceed the parent's.  Specifically:

     1.  The child's capability set MUST be a subset of the parent's

     2.  The child's trust score MUST NOT exceed the parent's

     3.  The child's spend limits MUST NOT exceed the parent's

     4.  The child's scope MUST be equal to or narrower than the
         parent's

     5.  The child's delegation depth MUST be parent's depth plus one

     The issuing CA MUST enforce this invariant.  Relying parties
     SHOULD verify it by walking the delegation chain.


  9.2.  Delegation Issuance

     When parent Agent A requests delegation to child Agent B:

     1.  Agent A presents its certificate and the requested child
         capabilities to the CA.

     2.  The CA verifies Agent A's certificate is valid and its trust
         score meets a minimum delegation threshold.

     3.  The CA verifies the requested child capabilities satisfy the
         monotonic attenuation invariant.

     4.  The CA verifies the delegation depth would not exceed
         maxDelegationDepth.

     5.  The CA issues Agent B's certificate with the AgentDelegation
         extension containing Agent A's certificate hash.


  9.3.  Cascade Revocation

     When a parent agent's certificate is revoked, all descendant
     certificates in the delegation chain MUST be automatically
     revoked.  The CA maintains a delegation tree index and traverses
     it upon revocation.  OCSP responses for descendant certificates
     MUST immediately return "revoked" status.


  10.  Federation

  10.1.  Trust Bundle Exchange

     Organizations publish APKI trust bundles at a well-known URI:

         https://{trust-domain}/.well-known/apki-trust-bundle

     A trust bundle is a JSON document containing:

         {
             "trust_domain": "cybersecai.co.uk",
             "version": 1,
             "issued_at": "2026-04-10T12:00:00Z",
             "expires_at": "2026-04-11T12:00:00Z",
             "ca_certificates": [
                 "<base64-encoded DER certificate>"
             ],
             "minimum_trust_score": 40,
             "supported_algorithms": ["ES256", "Ed25519"]
         }

     Trust bundles MUST be served over HTTPS.  Trust bundles SHOULD
     be refreshed at least daily.  This format is compatible with
     SPIFFE trust bundle federation.


  10.2.  Federation Verification

     When Organization A receives a request from an agent certified
     by Organization B's CA:

     1.  Organization A retrieves Organization B's trust bundle
         (cached with configurable TTL).

     2.  Organization A verifies the agent's certificate chain against
         Organization B's trust bundle.

     3.  Organization A checks the agent's trust score against its
         minimum threshold for federated agents.

     4.  If all checks pass, access is granted per Organization A's
         federation policies.


  10.3.  Trust Score Mapping

     Organizations MAY define trust score mapping functions to
     translate between different scoring criteria.  For example,
     Organization A may consider Organization B's agents to be
     10 points less trustworthy due to lower attestation requirements.

     The mapping function is applied after retrieving the certificate
     trust score and before comparing against the local minimum
     threshold.


  11.  Security Considerations

  11.1.  Threat Model

     This section defines the threat model for APKI.  The analysis
     follows the methodology of [RFC3552] and considers adversaries
     at multiple layers of the APKI architecture.

  11.1.1.  Attacker Capabilities

     APKI considers the following attacker classes:

     Network Attacker (Dolev-Yao):  An attacker who can observe,
        intercept, modify, and inject messages on any network path.
        This is the standard Internet threat model.  APKI mitigates
        this through TLS for all communications and cryptographic
        signatures on all certificates, timestamps, and trust bundles.

     Compromised Agent:  An agent whose private key has been
        extracted or whose runtime has been compromised (e.g., via
        prompt injection, model manipulation, or host compromise).
        APKI mitigates this through short-lived certificates, trust
        decay, and cascade revocation.

     Malicious Operator:  An organization that operates agents with
        the intent to deceive relying parties about the agents'
        capabilities, trust level, or provenance.  APKI mitigates
        this through Transparency Logs, third-party attestation, and
        federated trust with minimum score thresholds.

     Compromised CA:  An Organizational Intermediate CA whose private
        key has been compromised, enabling issuance of arbitrary agent
        certificates.  APKI mitigates this through Transparency Logs
        (detection), Root CA revocation (response), and multi-log
        consistency checks (prevention of silent mis-issuance).

     Insider Attacker:  A human with legitimate access to the CA or
        Trust Score Computation Engine who abuses their position to
        inflate scores, issue unauthorized certificates, or suppress
        revocations.  APKI mitigates this through separation of
        duties (CA operator vs. score computation), Transparency Log
        audit trails, and the requirement for multiple independent
        log operators.

  11.1.2.  Assets Under Protection

     The following assets are protected by APKI:

     Agent Identity:  The binding between an agent's public key and
        its agent URI.  Compromise enables impersonation.

     Trust Score Integrity:  The accuracy of trust scores embedded
        in certificates.  Manipulation enables privilege escalation.

     Delegation Chain Integrity:  The correctness of parent-child
        relationships and the monotonic attenuation invariant.
        Compromise enables unauthorized capability expansion.

     Capability Constraints:  The binding between an agent's identity
        and its permitted operations.  Bypass enables unauthorized
        actions (financial transactions, data access, tool invocation).

     Transparency Log Integrity:  The append-only property of logs
        and the completeness of log entries.  Compromise enables
        undetected mis-issuance.

     Model Provenance:  The accuracy of claims about which AI model
        powers an agent.  Falsification enables compliance violations
        in regulated industries.

  11.1.3.  Out of Scope

     The following threats are explicitly out of scope for APKI:

     1.  Compromise of the offline Root CA (assumed to be physically
         secured in an air-gapped HSM environment)

     2.  Vulnerabilities in the underlying AI model (prompt injection,
         jailbreaking, hallucination) -- APKI provides identity and
         trust, not model safety

     3.  Side-channel attacks on cryptographic implementations

     4.  Compromise of all Transparency Log operators simultaneously

     5.  Quantum computing attacks on classical algorithms (addressed
         by post-quantum migration path in Section 11.3)

  11.2.  Threat Analysis

  11.2.1.  T1: Trust Score Inflation

     Threat:  An attacker fabricates positive behavioural signals to
        inflate an agent's trust score, causing the CA to issue
        certificates with artificially high scores.

     Impact:  HIGH.  An agent with an inflated score gains access to
        operations requiring ELEVATED or FULL trust (financial
        transactions, regulated data, production environments).

     Likelihood:  MODERATE.  Requires the ability to submit
        authenticated behavioural signals to the Trust Score
        Computation Engine.

     Mitigations:
        -  Behavioural signals MUST be authenticated using the
           reporting relying party's credentials
        -  The Trust Score Computation Engine MUST rate-limit signal
           acceptance (RECOMMENDED: maximum 10 signals per agent per
           hour from any single relying party)
        -  Anomaly detection SHOULD flag sudden score increases
           (e.g., more than 20 points in 24 hours)
        -  Trust scores SHOULD incorporate multiple independent signal
           sources; no single relying party should be able to move a
           score by more than 15 points
        -  Historical signal patterns SHOULD be compared against
           population baselines

  11.2.2.  T2: Trust Score Gaming via Decay Reset

     Threat:  An attacker allows an agent's score to decay, then
        generates a burst of positive signals to obtain a fresh
        certificate with a higher-than-warranted score.

     Impact:  MODERATE.  The reset score is bounded by the CA's
        computation algorithm and cannot exceed the maximum initial
        score for the agent's attestation level.

     Mitigations:
        -  The CA MUST NOT issue a certificate with a score higher
           than the agent's historical peak minus any penalty history
        -  Decay history MUST be maintained across certificate
           renewals
        -  The decay rate SHOULD increase for agents with a history
           of rapid score fluctuations

  11.2.3.  T3: Delegation Chain Privilege Escalation

     Threat:  An attacker creates a delegation chain that bypasses
        the monotonic attenuation invariant, resulting in a child
        agent with broader capabilities than its parent.

     Impact:  CRITICAL.  The child agent could execute operations
        (e.g., financial transactions, data exfiltration) that the
        parent was not authorized to delegate.

     Likelihood:  LOW if the CA correctly implements attenuation
        checks.  Higher if the CA has implementation bugs.

     Mitigations:
        -  The CA MUST verify the monotonic attenuation invariant
           before issuing any delegated certificate
        -  Relying parties SHOULD independently verify the invariant
           by walking the delegation chain (checking each parent
           certificate's capabilities are a superset of the child's)
        -  The delegation depth MUST be checked against
           maxDelegationDepth at issuance
        -  Implementations MUST treat attenuation verification
           failures as CRITICAL errors and refuse issuance

  11.2.4.  T4: Rogue Certificate Issuance

     Threat:  A compromised Organizational Intermediate CA issues
        agent certificates with fabricated trust scores, false
        capabilities, or spoofed agent URIs.

     Impact:  CRITICAL within the compromised trust domain.  Agents
        with fraudulent certificates could impersonate legitimate
        agents, execute unauthorized operations, and evade detection.

     Likelihood:  LOW (requires CA key compromise or insider attack).

     Mitigations:
        -  All certificates MUST be submitted to at least one
           Transparency Log before issuance; certificates without
           valid SATs MUST be rejected by relying parties
        -  Organizations MUST monitor Transparency Logs for
           certificates issued within their trust domain
        -  The Root CA MUST maintain the ability to revoke any
           Intermediate CA certificate within 60 seconds
        -  Cross-log consistency checks (gossip protocols) SHOULD
           detect split-view attacks where a rogue CA submits
           different certificates to different logs
        -  Relying parties SHOULD require SATs from at least two
           independent logs for ELEVATED and FULL trust operations

  11.2.5.  T5: Transparency Log Manipulation

     Threat:  An attacker compromises a Transparency Log operator
        and inserts, modifies, or suppresses log entries.

     Impact:  HIGH.  Enables undetected rogue certificate issuance
        (T4) or concealment of compromised agents.

     Likelihood:  LOW if multiple independent logs are required.

     Mitigations:
        -  Log operators MUST sign tree heads at regular intervals
           (RECOMMENDED: every 60 seconds)
        -  Monitors MUST verify log consistency by requesting
           inclusion proofs and consistency proofs
        -  Relying parties SHOULD accept SATs only from logs that
           have been independently audited within the last 24 hours
        -  A minimum of two independent logs operated by different
           entities in different jurisdictions is RECOMMENDED
        -  Log operators SHOULD implement append-only storage with
           hardware write-once guarantees where available

  11.2.6.  T6: Agent Impersonation via Key Theft

     Threat:  An attacker extracts an agent's private key and uses
        it to impersonate the agent during the certificate's validity
        period.

     Impact:  HIGH.  The attacker can perform any operation the
        legitimate agent is authorized for.

     Likelihood:  MODERATE for software-stored keys.  LOW for
        HSM-bound keys.

     Mitigations:
        -  Short-lived certificates (default 1 hour) limit the
           window of exposure
        -  HSM-bound keys (PKCS#11, TPM, cloud KMS) prevent key
           extraction; implementations SHOULD default to HSM storage
           for agents with ELEVATED or FULL trust
        -  Trust decay reduces the value of stolen credentials over
           time even within the validity period
        -  Challenge-response protocols at the application layer
           provide additional proof-of-possession beyond certificate
           presentation
        -  Relying parties MAY require DPoP (Demonstration of
           Proof-of-Possession) for high-value operations

  11.2.7.  T7: Trust Domain Spoofing

     Threat:  An attacker registers a trust domain similar to a
        legitimate organization (e.g., cybersecai.co.uk vs.
        cybersec-ai.co.uk) and issues agent certificates that
        appear to belong to the legitimate organization.

     Impact:  HIGH.  Relying parties may trust spoofed agents,
        leading to data exposure or financial loss.

     Likelihood:  MODERATE.  Requires registering a similar domain
        and establishing an APKI CA, but does not require
        compromising any legitimate infrastructure.

     Mitigations:
        -  Trust bundles MUST be exchanged via pre-configured,
           authenticated channels (not auto-discovered)
        -  Federation agreements MUST be established out-of-band
           with identity verification of the counterparty
        -  Relying parties MUST NOT accept agent certificates from
           trust domains not present in their configured trust bundle
           set
        -  Transparency Log monitors SHOULD alert on new trust
           domains that are typographically similar to existing
           monitored domains

  11.2.8.  T8: Capability Constraint Bypass

     Threat:  An agent or its operator attempts to invoke operations
        beyond those specified in the AgentCapabilities extension,
        hoping that the relying party does not enforce capability
        checks.

     Impact:  HIGH.  Unauthorized financial transactions, data
        access, or tool invocations.

     Likelihood:  HIGH if relying parties treat capability checking
        as optional.

     Mitigations:
        -  Relying parties MUST verify the AgentCapabilities
           extension before granting access to any protected resource
        -  The toolUri in the capability MUST match the resource
           being accessed; wildcard matching MUST NOT be used
        -  Spend limits MUST be enforced by the relying party
           (payment processor, API gateway) independently of the
           agent's self-reported spending
        -  Rate limits MUST be enforced server-side using the
           certificate's rate constraint values
        -  Implementations MUST fail closed: if the AgentCapabilities
           extension is absent or unparseable, access MUST be denied

  11.2.9.  T9: Model Provenance Falsification

     Threat:  An operator falsifies the AgentProvenance extension,
        claiming an agent uses an approved model (e.g., Claude) when
        it actually uses an unapproved or fine-tuned model.

     Impact:  MODERATE to HIGH in regulated industries where model
        approval is required for compliance.

     Likelihood:  MODERATE.  Self-declared provenance is trivially
        falsifiable.  CA-verified provenance is harder to fake.

     Mitigations:
        -  Relying parties requiring high assurance MUST require
           attestationMethod of caVerified (1) or higher
        -  CAs providing caVerified attestation MUST verify model
           provenance through technical means (API introspection,
           model fingerprinting, or framework-level attestation)
        -  Third-party attestation (2) SHOULD be required for
           regulated use cases (financial services, healthcare)
        -  Hardware-bound attestation (3) using TEE attestation
           reports provides the highest assurance and SHOULD be
           used where available
        -  Build hashes in the AgentProvenance extension SHOULD be
           verified against a known-good build registry maintained
           by the model provider

  11.2.10.  T10: Cascade Revocation Evasion

     Threat:  A child agent detects that its parent is about to be
        revoked and races to perform unauthorized operations before
        the cascade revocation propagates.

     Impact:  MODERATE.  Limited by the speed of cascade propagation
        and the short validity period of certificates.

     Likelihood:  LOW.  Requires the child agent to have advance
        knowledge of the parent's revocation.

     Mitigations:
        -  Cascade revocation MUST propagate to OCSP responders
           within 1 second of the parent's revocation
        -  CRLs MUST be updated within 60 seconds
        -  Relying parties performing high-value operations SHOULD
           perform real-time OCSP checks rather than relying on
           cached CRL data
        -  The delegation tree index maintained by the CA MUST be
           updated atomically with the parent's revocation

  11.3.  Post-Quantum Considerations

     APKI certificates MUST support migration to post-quantum
     algorithms as standardized by NIST.  The following migration
     path is RECOMMENDED:

     Phase 1 (Current):  ECDSA P-256 and Ed25519 as primary
        algorithms.

     Phase 2 (Transition):  Composite signatures combining a
        classical algorithm (ECDSA P-256 or Ed25519) with a
        post-quantum algorithm (ML-DSA-65) in the same certificate.
        Both signatures MUST be valid for the certificate to be
        accepted.

     Phase 3 (Post-Quantum):  ML-DSA-65 or SLH-DSA as standalone
        algorithms once classical algorithms are deprecated.

     Implementations MUST support algorithm agility in all protocol
     messages to enable migration without infrastructure replacement.
     The Signature Algorithm field in agent certificates MUST be
     checked by relying parties against a locally configured list of
     acceptable algorithms.

  11.4.  Privacy Considerations

     Agent URIs may reveal organizational structure, agent types,
     and deployment topology.  The following privacy measures are
     RECOMMENDED:

     1.  Organizations SHOULD use opaque instance identifiers rather
         than sequential or predictable values

     2.  The type component of agent URIs SHOULD use generic
         functional names rather than names that reveal business
         logic

     3.  Transparency Log entries are public; organizations MUST
         consider that agent registrations, capabilities, and trust
         scores in Transparency Logs are observable by any party

     4.  Trust score values in certificates may reveal information
         about an agent's operational history; organizations
         operating in sensitive contexts SHOULD evaluate whether
         this information leakage is acceptable

     5.  Federation trust bundles reveal the existence of
         inter-organizational relationships; organizations SHOULD
         consider whether publishing trust bundles at well-known
         URIs exposes sensitive partnership information

  11.5.  Denial of Service Considerations

     The following components are susceptible to denial of service:

     Transparency Logs:  Volumetric attacks against log submission
        endpoints can prevent certificate issuance.  Log operators
        MUST implement rate limiting, geographic distribution, and
        DDoS mitigation.

     OCSP Responders:  Overwhelming OCSP responders can prevent
        revocation checking.  OCSP stapling SHOULD be used to reduce
        responder load.  Relying parties MUST define a fail-closed
        policy when OCSP is unreachable.

     Trust Score Computation Engine:  Flooding the engine with
        behavioural signals can cause score instability.  The engine
        MUST implement per-source rate limiting and signal
        authentication.

     Federation Endpoints:  Trust bundle endpoints may be targeted
        to prevent cross-organizational trust establishment.  Trust
        bundles SHOULD be cached with configurable TTLs and served
        from CDN infrastructure.


  12.  IANA Considerations

     This document requests the following IANA registrations:

  12.1.  URI Scheme Registration

     Scheme name:  agent

     Status:  Permanent

     Applications/protocols:  Agent Public Key Infrastructure (APKI)

     Contact:  IETF

     Change controller:  IETF

     Reference:  This document, Section 4


  12.2.  SMI Security for PKIX Certificate Extension OIDs

     The following OIDs are requested under
     id-pe (1.3.6.1.5.5.7.1):

         id-pe-agentTrustScore              (TBD1)
         id-pe-agentCapabilities            (TBD2)
         id-pe-agentDelegation              (TBD3)
         id-pe-agentProvenance              (TBD4)
         id-pe-agentBehaviouralAttestation  (TBD5)


  12.3.  Well-Known URI Registration

     URI suffix:  apki-trust-bundle

     Change controller:  IETF

     Specification document:  This document, Section 10.1

     Related information:  None


  13.  References

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

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280,
                May 2008.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174,
                DOI 10.17487/RFC8174, May 2017.

     [RFC9162]  Laurie, B., Messeri, E., and R. Stradling,
                "Certificate Transparency Version 2.0", RFC 9162,
                DOI 10.17487/RFC9162, December 2021.


  13.2.  Informative References

     [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
                Transparency", RFC 6962, DOI 10.17487/RFC6962,
                June 2013.

     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019.

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

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

     [SPIFFE]   SPIFFE Project, "Secure Production Identity Framework
                for Everyone (SPIFFE)", https://spiffe.io/.

     [I-D.ietf-wimse-arch]
                WIMSE Working Group, "Workload Identity in Multi-
                System Environments Architecture",
                Internet-Draft draft-ietf-wimse-arch, 2024.

     [I-D.niyikiza-oauth-attenuating-agent-tokens]
                Niyikiza, E., "Attenuating Authorization Tokens for
                Autonomous AI Agents", Internet-Draft
                draft-niyikiza-oauth-attenuating-agent-tokens-00,
                2026.

     [I-D.sharif-mcps-secure-mcp]
                Sharif, R., "MCPS: Cryptographic Security Layer for
                the Model Context Protocol", Internet-Draft
                draft-sharif-mcps-secure-mcp, 2026.

     [I-D.sharif-agent-identity-framework]
                Sharif, R., "Agent Identity Framework: Trust and
                Identity for Autonomous AI Agents", Internet-Draft
                draft-sharif-agent-identity-framework-00, 2026.

     [I-D.sharif-agent-payment-trust]
                Sharif, R., "Agent Payment Trust: Dynamic Financial
                Authorisation for Autonomous AI Agents",
                Internet-Draft draft-sharif-agent-payment-trust,
                2026.


  Appendix A.  ASN.1 Module

     APKI-2026
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-apki-2026(TBD) }

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN

     IMPORTS
         Extensions
             FROM PKIX1Explicit88
                 { iso(1) identified-organization(3) dod(6)
                   internet(1) security(5) mechanisms(5) pkix(7)
                   id-mod(0) id-pkix1-explicit(18) }
         ;

     -- OID Arc for APKI Extensions

     id-pe-agentTrustScore OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) pe(1) TBD1 }

     id-pe-agentCapabilities OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) pe(1) TBD2 }

     id-pe-agentDelegation OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) pe(1) TBD3 }

     id-pe-agentProvenance OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) pe(1) TBD4 }

     id-pe-agentBehaviouralAttestation OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) pe(1) TBD5 }


     -- AgentTrustScore Extension

     AgentTrustScore ::= SEQUENCE {
         score               INTEGER (0..100),
         trustTier           ENUMERATED {
             untrusted           (0),
             restricted          (1),
             standard            (2),
             elevated            (3),
             full                (4)
         },
         decayRate           INTEGER (0..100),
         lastUpdated         GeneralizedTime,
         computationMethod   UTF8String OPTIONAL
     }


     -- AgentCapabilities Extension

     AgentCapabilities ::= SEQUENCE {
         capabilities  SEQUENCE OF Capability
     }

     Capability ::= SEQUENCE {
         toolUri       IA5String,
         scope         UTF8String,
         spendLimit    SpendConstraint OPTIONAL,
         rateLimit     RateConstraint OPTIONAL
     }

     SpendConstraint ::= SEQUENCE {
         maxPerTransaction  INTEGER OPTIONAL,
         maxPerPeriod       INTEGER OPTIONAL,
         periodSeconds      INTEGER OPTIONAL,
         currency           PrintableString
     }

     RateConstraint ::= SEQUENCE {
         maxRequests    INTEGER,
         periodSeconds  INTEGER
     }


     -- AgentDelegation Extension

     AgentDelegation ::= SEQUENCE {
         parentCertHash      OCTET STRING (SIZE(32)),
         delegationDepth     INTEGER (0..255),
         maxDelegationDepth  INTEGER (0..255),
         attenuationRules    AttenuationRules,
         humanPrincipal      UTF8String OPTIONAL
     }

     AttenuationRules ::= SEQUENCE {
         capabilitiesSubset  BOOLEAN DEFAULT TRUE,
         maxTrustScore       INTEGER (0..100) OPTIONAL,
         maxSpendLimit       INTEGER OPTIONAL,
         scopeNarrowing      UTF8String OPTIONAL
     }


     -- AgentProvenance Extension

     AgentProvenance ::= SEQUENCE {
         modelFamily     UTF8String,
         modelVersion    UTF8String,
         framework       UTF8String,
         organizationId  UTF8String,
         buildHash       OCTET STRING (SIZE(32)) OPTIONAL,
         attestEvidence  OCTET STRING OPTIONAL
     }


     -- AgentBehaviouralAttestation Extension

     AgentBehaviouralAttestation ::= SEQUENCE {
         declaredCapabilitiesHash  OCTET STRING (SIZE(32)),
         attestationMethod         ENUMERATED {
             selfDeclared    (0),
             caVerified      (1),
             thirdParty      (2),
             hardwareBound   (3)
         },
         attestorIdentity  UTF8String OPTIONAL,
         attestationTime   GeneralizedTime,
         evidenceUri       IA5String OPTIONAL
     }


     -- Signed Agent Timestamp

     SignedAgentTimestamp ::= SEQUENCE {
         version    INTEGER,
         logId      OCTET STRING (SIZE(32)),
         timestamp  INTEGER,
         certHash   OCTET STRING (SIZE(32)),
         signature  OCTET STRING
     }

     END


  Appendix B.  Example Agent Certificate

     The following is a conceptual representation of an APKI agent
     certificate (actual DER encoding omitted for readability):

     Certificate:
         Version: 3
         Serial Number: 7a:3b:c4:d5:e6:f7:08:19
         Signature Algorithm: ecdsa-with-SHA256
         Issuer: CN=CyberSecAI Org CA, O=CyberSecAI Ltd, C=GB
         Validity:
             Not Before: Apr 10 12:00:00 2026 UTC
             Not After:  Apr 10 13:00:00 2026 UTC
         Subject: (empty)
         Subject Public Key Info:
             Algorithm: EC (P-256)
             Public Key: 04:a1:b2:c3:...
         X509v3 Extensions:
             Subject Alternative Name:
                 URI: agent://cybersecai.co.uk/payments/bot/a1b2c3
             AgentTrustScore:
                 Score: 75
                 Tier: ELEVATED
                 Decay Rate: 2 points/hour
                 Last Updated: Apr 10 12:00:00 2026 UTC
             AgentCapabilities:
                 Tool: mcp://stripe.com/charges/create
                     Scope: payments
                     Max Per Transaction: 100000 (GBP 1000.00)
                     Max Per Period: 500000 (GBP 5000.00/day)
                     Rate: 60 requests/3600 seconds
                 Tool: mcp://sanctions.agentpass.co.uk/screen
                     Scope: aml-screening
                     Rate: 120 requests/3600 seconds
             AgentDelegation:
                 Parent Cert Hash: sha256:8f4e2d...
                 Delegation Depth: 1
                 Max Delegation Depth: 3
                 Attenuation: capabilities-subset=TRUE
                 Human Principal: raza.sharif@cybersecai.co.uk
             AgentProvenance:
                 Model: claude / opus-4-6
                 Framework: mcp-sdk
                 Organization: CyberSecAI Ltd
                 Build Hash: sha256:3c7b9a...
             AgentBehaviouralAttestation:
                 Capabilities Hash: sha256:5d1e8f...
                 Method: caVerified
                 Attestor: CyberSecAI Org CA
                 Time: Apr 10 11:55:00 2026 UTC
             Signed Agent Timestamps:
                 Log: CyberSecAI-ATL-01
                 Time: Apr 10 11:59:58 2026 UTC
                 Signature: 30:45:02:21:...
         Signature Algorithm: ecdsa-with-SHA256
         Signature Value: 30:46:02:21:...


  Appendix C.  Comparison with Existing Systems

     +------------------+-------+------+------+------+------+------+
     | Feature          | X.509 |SPIFFE| WIMSE| OAuth | DID  | APKI |
     +------------------+-------+------+------+------+------+------+
     | Cert-based       | Yes   | Yes  | No   | No   | No   | Yes  |
     | Trust scoring    | No    | No   | No   | No   | No   | Yes  |
     | Capabilities     | No    | No   | No   | Scope | VC   | Yes  |
     | Delegation       | Proxy | No   | No   | Chain | No   | Yes  |
     | Provenance       | No    | No   | No   | No   | No   | Yes  |
     | Transparency     | CT    | No   | No   | No   | No   | ATL  |
     | Short-lived      | Rare  | Yes  | N/A  | Yes  | N/A  | Yes  |
     | Agent-specific   | No    | No   | No   | No   | No   | Yes  |
     | Federation       | Cross | Yes  | Yes  | No   | Yes  | Yes  |
     +------------------+-------+------+------+------+------+------+

     APKI is the first system to combine certificate-based identity
     with graduated trust scoring, capability constraints, delegation
     chains, model provenance, and transparency logging specifically
     designed for autonomous AI agents.


  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     London
     United Kingdom

     Email: raza.sharif@outlook.com
     URI:   https://cybersecai.co.uk


name: draft-nyantakyi-vaip-agent-identity
rev: 01
title: Vorim Agent Identity Protocol (VAIP)
time: 2026-04-11T03:49:37Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-13T03:49:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:41.698326+00:00
source: ietf
abstract:
  This document defines the Vorim Agent Identity Protocol (VAIP), a
     standard for establishing verifiable cryptographic identity, fine-
     grained permissions, trust scoring, and tamper-evident audit trails
     for autonomous AI agents.

     As AI agents increasingly perform actions autonomously in enterprise
     systems, existing identity protocols designed for human users or
     static services are insufficient.  VAIP addresses this gap by
     providing cryptographic primitives and data structures for issuing,
     verifying, and managing agent identities in multi-tenant
     environments.

     The protocol uses Ed25519 for agent identity, SHA-256 for audit
     integrity, and defines seven hierarchical permission scopes with
     time-bounded grants and rate limiting.

full_text:
  Independent Submission                                      K. Nyantakyi
  Internet-Draft                                                  Vorim AI
  Intended status: Standards Track                              April 2026
  Expires: 12 October 2026


                    Vorim Agent Identity Protocol (VAIP)
                   draft-nyantakyi-vaip-agent-identity-01

  Abstract

     This document defines the Vorim Agent Identity Protocol (VAIP), a
     standard for establishing verifiable cryptographic identity, fine-
     grained permissions, trust scoring, and tamper-evident audit trails
     for autonomous AI agents.

     As AI agents increasingly perform actions autonomously in enterprise
     systems, existing identity protocols designed for human users or
     static services are insufficient.  VAIP addresses this gap by
     providing cryptographic primitives and data structures for issuing,
     verifying, and managing agent identities in multi-tenant
     environments.

     The protocol uses Ed25519 for agent identity, SHA-256 for audit
     integrity, and defines seven hierarchical permission scopes with
     time-bounded grants and rate limiting.

  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 3 October 2026.

  Copyright Notice

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



  Nyantakyi                Expires 12 October 2026                [Page 1]


  Internet-Draft                    VAIP                        April 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.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Design Principles . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Identity Format . . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Keypair Generation  . . . . . . . . . . . . . . . . . . .   5
       2.3.  Key Fingerprint . . . . . . . . . . . . . . . . . . . . .   6
       2.4.  Agent Lifecycle . . . . . . . . . . . . . . . . . . . . .   6
       2.5.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Permission Model  . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Scopes  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Permission Grants . . . . . . . . . . . . . . . . . . . .   7
       3.3.  Rate Limits . . . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Permission Check Flow . . . . . . . . . . . . . . . . . .   8
     4.  Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Event Schema  . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Hash Format . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Event Signatures  . . . . . . . . . . . . . . . . . . . .   9
       4.4.  Immutability  . . . . . . . . . . . . . . . . . . . . . .   9
       4.5.  Signed Audit Bundles  . . . . . . . . . . . . . . . . . .   9
     5.  Trust Scoring . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.2.  Scoring Algorithm . . . . . . . . . . . . . . . . . . . .   9
       5.3.  Trust Verification  . . . . . . . . . . . . . . . . . . .  10
       5.4.  Trust Badges  . . . . . . . . . . . . . . . . . . . . . .  10
     6.  Conformance Levels  . . . . . . . . . . . . . . . . . . . . .  10
     7.  Credential Delegation (Future Extension)  . . . . . . . . . .  10
       7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.2.  Multi-Hop Delegation Chains . . . . . . . . . . . . . . .  11
       7.3.  Ephemeral Agent Identity  . . . . . . . . . . . . . . . .  12
       7.4.  Integration with Credential Delegation Protocols  . . . .  12
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
       8.1.  Cryptographic Choices . . . . . . . . . . . . . . . . . .  12
       8.2.  Private Key Handling  . . . . . . . . . . . . . . . . . .  13
       8.3.  Multi-Tenant Isolation  . . . . . . . . . . . . . . . . .  13
       8.4.  Transport Security  . . . . . . . . . . . . . . . . . . .  13



  Nyantakyi                Expires 12 October 2026                [Page 2]


  Internet-Draft                    VAIP                        April 2026


       8.5.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  13
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
       10.2.  Informative References . . . . . . . . . . . . . . . . .  15
     Appendix A.  Reference Implementation . . . . . . . . . . . . . .  15
     Appendix B.  Relationship to Existing Standards . . . . . . . . .  15
     Appendix C.  Regulatory Alignment . . . . . . . . . . . . . . . .  16
     Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

  1.1.  Problem Statement

     Autonomous AI agents are increasingly deployed to perform real-world
     tasks: executing code, sending messages, making financial
     transactions, and accessing sensitive resources.  Unlike human users,
     agents lack a standardised identity layer.  There is no widely
     adopted protocol for answering fundamental questions about an agent:

     *  Who is this agent?  (Identity)

     *  What is it allowed to do?  (Permissions)

     *  What has it done?  (Audit)

     *  Should I trust it?  (Trust)

     Existing identity systems (OAuth 2.0, API keys, X.509 certificates)
     were designed for human users or static services.  They do not
     address the unique requirements of autonomous agents that act
     independently, accumulate behavioural history, and require dynamic
     trust assessment.

     Non-human identities outnumber human identities by approximately 50:1
     in the average enterprise, yet no standardised infrastructure exists
     for managing them.

  1.2.  Design Principles

     1.  Cryptographic verifiability: Every identity claim MUST be
         verifiable through public key cryptography without relying on a
         central authority at verification time.

     2.  Minimal trust: Private keys are generated once and never stored
         by the issuing system.  The agent or its operator is the sole
         custodian of its private key.



  Nyantakyi                Expires 12 October 2026                [Page 3]


  Internet-Draft                    VAIP                        April 2026


     3.  Auditability: Every action performed by an agent MUST be logged
         in a tamper-evident ledger.  Audit records MUST support
         independent integrity verification.

     4.  Interoperability: The protocol uses widely supported
         cryptographic standards (Ed25519, SHA-256) and data formats
         (JSON, PEM) to enable cross-platform verification.

     5.  Multi-tenancy: All identities, permissions, and audit records are
         scoped to an organisation.  No data leaks across tenants.

  1.3.  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] when, and only when, they appear in all capitals, as
     shown here.

     Agent  An autonomous software entity that performs actions on behalf
        of an organisation.

     Organisation  A tenant entity that owns and manages agents.

     Operator  A human user who registers and configures agents within an
        organisation.

     Scope  A named permission that authorises a specific category of
        action.

     Trust Score  A numeric assessment (0-100) of an agent's reliability
        based on behavioural history.

     Audit Event  An immutable record of an action performed by or on
        behalf of an agent.

  2.  Agent Identity

  2.1.  Identity Format

     Every agent MUST be assigned a unique agent identifier upon
     registration.  The identifier follows this format:

     agid_{org_slug}_{random}

     Where:





  Nyantakyi                Expires 12 October 2026                [Page 4]


  Internet-Draft                    VAIP                        April 2026


     *  "agid_" is a fixed prefix identifying the string as a VAIP agent
        identifier

     *  {org_slug} is a truncated (up to 8 characters) alphanumeric slug
        identifying the owning organisation

     *  {random} is a cryptographically random string (8 characters,
        derived from UUID v4)

     Example: agid_acme_a1b2c3d4

     Agent identifiers MUST be globally unique and MUST NOT be reused
     after revocation.

  2.2.  Keypair Generation

     Each agent MUST be assigned an Ed25519 [RFC8032] keypair at
     registration time.  Ed25519 was chosen for the following properties:

     *  128-bit security level

     *  Fast key generation, signing, and verification

     *  Small key and signature sizes (32-byte public keys, 64-byte
        signatures)

     *  Deterministic signatures (no nonce reuse vulnerabilities)

     *  Resistance to timing attacks

     The keypair MUST be generated as follows:

     1.  Generate an Ed25519 keypair using the system's cryptographic
         random number generator

     2.  Encode the public key in SPKI/PEM format

     3.  Encode the private key in PKCS#8/PEM format

     4.  Compute the key fingerprint

     5.  Return the private key to the operator exactly once

     6.  Store the public key and fingerprint; never store the private key







  Nyantakyi                Expires 12 October 2026                [Page 5]


  Internet-Draft                    VAIP                        April 2026


  2.3.  Key Fingerprint

     A key fingerprint is a SHA-256 [RFC6234] hash of the PEM-encoded
     public key, represented as a hexadecimal string (64 characters):

     fingerprint = SHA-256(public_key_pem)[0:64]

     The fingerprint serves as a compact, verifiable reference to an
     agent's identity.  It MUST be included in trust verification
     responses and MAY be used for identity comparison without
     transmitting the full public key.

  2.4.  Agent Lifecycle

     An agent MUST exist in exactly one of the following states at any
     time:

     *  pending: Registered but not yet activated

     *  active: Fully operational, permissions enforceable

     *  suspended: Temporarily disabled, can be reactivated

     *  revoked: Permanently disabled, cannot be reactivated

     *  expired: Past its expiration timestamp

     A revoked agent MUST NOT be reactivated.  Its identifier MUST NOT be
     reused.

  2.5.  Key Rotation

     An agent's keypair MAY be rotated by revoking the current agent and
     registering a new agent with the same metadata.  The new agent MUST
     receive a new agent_id and keypair.

  3.  Permission Model

  3.1.  Scopes

     VAIP defines seven permission scopes.  Each scope authorises a
     category of agent actions:









  Nyantakyi                Expires 12 October 2026                [Page 6]


  Internet-Draft                    VAIP                        April 2026


               +=============+===================+============+
               | Scope       | Identifier        | Risk Level |
               +=============+===================+============+
               | Read        | agent:read        | Low        |
               +-------------+-------------------+------------+
               | Write       | agent:write       | Medium     |
               +-------------+-------------------+------------+
               | Execute     | agent:execute     | Medium     |
               +-------------+-------------------+------------+
               | Transact    | agent:transact    | High       |
               +-------------+-------------------+------------+
               | Communicate | agent:communicate | Medium     |
               +-------------+-------------------+------------+
               | Delegate    | agent:delegate    | High       |
               +-------------+-------------------+------------+
               | Elevate     | agent:elevate     | Critical   |
               +-------------+-------------------+------------+

                                   Table 1

     Scopes are not hierarchical by default.  Possessing agent:write does
     not imply agent:read.  Each scope MUST be granted independently.

  3.2.  Permission Grants

     A permission grant binds a scope to an agent with optional
     constraints including:

     *  valid_from: When the grant becomes effective

     *  valid_until: Optional expiration time

     *  rate_limit: Maximum uses within a time window

     *  conditions: Additional constraints (e.g., IP allowlists)

  3.3.  Rate Limits

     A rate limit constrains how frequently a scope can be exercised:

     { "max": 1000, "window": "1h" }

     Supported windows: "1m" (minute), "1h" (hour), "1d" (day).

     When an agent exceeds its rate limit, permission checks MUST return
     denied with reason RATE_LIMIT_EXCEEDED.





  Nyantakyi                Expires 12 October 2026                [Page 7]


  Internet-Draft                    VAIP                        April 2026


  3.4.  Permission Check Flow

     When an agent requests to perform an action, the system MUST:

     1.  Validate agent_id exists and status is active

     2.  Check cache for recent permission decision

     3.  If cache miss: query grants, filter by validity and revocation,
         evaluate rate limits and conditions

     4.  Cache the decision (RECOMMENDED TTL: 300 seconds)

     5.  Return the permission check result

     Valid denial reasons: AGENT_NOT_FOUND, AGENT_NOT_ACTIVE,
     SCOPE_NOT_GRANTED, GRANT_EXPIRED, RATE_LIMIT_EXCEEDED,
     CONDITION_NOT_MET.

  4.  Audit Trail

  4.1.  Event Schema

     Every auditable action MUST produce an audit event including:

     *  event_id: Unique, time-sortable identifier (e.g., ULID)

     *  agent_id: Agent that performed the action

     *  org_id: Organisation context

     *  event_type: Category (tool_call, api_request, message_sent,
        permission_change, status_change, key_rotation)

     *  action: Specific action performed

     *  result: Outcome (success, denied, error)

     *  timestamp: ISO 8601 timestamp

     Optional fields include resource, input_hash, output_hash,
     permission, latency_ms, error_code, signature, and metadata.

  4.2.  Hash Format

     All hashes in audit events MUST use the format:

     sha256:{hex_digest}



  Nyantakyi                Expires 12 October 2026                [Page 8]


  Internet-Draft                    VAIP                        April 2026


     Where {hex_digest} is the lowercase hexadecimal representation of the
     SHA-256 hash.

  4.3.  Event Signatures

     Audit events MAY be signed by the agent that produced them.  When
     present, the signature field MUST contain an Ed25519 signature of the
     canonical JSON [RFC8259] representation of the event (excluding the
     signature field itself), encoded as:

     ed25519:{base64_signature}

  4.4.  Immutability

     Audit events MUST be append-only.  Once written, an event MUST NOT be
     modified or deleted except by automated retention policies.

  4.5.  Signed Audit Bundles

     Conforming systems MUST support exporting audit events as signed
     bundles.  A bundle contains the events array, event count, time
     range, organisation identifier, and a manifest field containing a
     SHA-256 hash of the JSON-serialised events array.

     Any modification to any event produces a different manifest hash,
     making tampering detectable.

  5.  Trust Scoring

  5.1.  Overview

     Trust scoring provides a quantitative assessment of an agent's
     reliability.  The score is a number from 0 to 100, computed from
     multiple behavioural and configuration factors.  Trust scores are
     dynamic, public, and composite.

  5.2.  Scoring Algorithm

     The trust score is computed as:

     score = base_score + status_factor + age_factor
             + success_rate_factor - denial_penalty
             - scope_breadth_penalty








  Nyantakyi                Expires 12 October 2026                [Page 9]


  Internet-Draft                    VAIP                        April 2026


     Base score: 50.  Status factor: active (+10), suspended (-20),
     revoked (score fixed at 0).  Age factor: >90 days (+15), >30 days
     (+10), >7 days (+5).  Success rate factor: round(success_rate * 15)
     over trailing 30-day window.  Denial penalty: -10 if denied_count
     exceeds 10% of total events.  Scope breadth penalty: -5 if agent
     holds more than 5 active scopes.  Final score clamped to [0, 100].

  5.3.  Trust Verification

     Conforming implementations MUST provide a public, unauthenticated
     endpoint for trust verification.  The response includes agent_id,
     verification status, trust score, active scopes, key fingerprint, and
     revocation status.

  5.4.  Trust Badges

     Conforming implementations SHOULD provide embeddable SVG trust badges
     displaying protocol name, verification status, and trust score with
     colour coding: green (80-100), amber (50-79), red (0-49).

  6.  Conformance Levels

     Implementations MAY conform to one or more levels:

     Level 1 - Identity  Agent registration with Ed25519 keypairs, key
        fingerprints, lifecycle management.

     Level 2 - Permissions  Level 1 plus seven permission scopes, time-
        bounded grants, rate limiting, cached permission checks.

     Level 3 - Audit  Level 2 plus audit event ingestion, schema
        compliance, SHA-256 hashing, event query with filtering.

     Level 4 - Trust  Level 3 plus trust score computation, public
        verification endpoint, embeddable trust badges.

     Level 5 - Full Conformance  Level 4 plus signed audit bundle export,
        Ed25519 event signatures, multi-format export, API key management.

  7.  Credential Delegation (Future Extension)

     This section outlines a future extension to VAIP for secure
     credential delegation across multi-agent systems.  This work is
     complementary to draft-sweeney-wimse-credential-delegation-00, which
     defines the wire protocol for OAuth token delegation.  VAIP's
     contribution is binding credential delegation to verified agent
     identities, permission scopes, and audit trails.




  Nyantakyi                Expires 12 October 2026               [Page 10]


  Internet-Draft                    VAIP                        April 2026


  7.1.  Overview

     When an agent needs to access a third-party service (e.g., Google
     Drive, GitHub, Salesforce) on behalf of a user, it requires OAuth
     credentials.  Credential delegation defines how an agent receives
     scoped, time-limited credentials without exposing raw refresh tokens
     or long-lived secrets.

     A conforming credential delegation system SHOULD:

     *  Verify the requesting agent's VAIP identity before issuing any
        credential

     *  Check the agent's permission scope (agent:read, agent:execute,
        etc.) against the requested OAuth scope

     *  Issue short-lived access tokens only; refresh tokens MUST remain
        in the delegation server's encrypted vault

     *  Record every credential issuance as an audit event in the agent's
        VAIP audit trail

     *  Support immediate revocation that propagates across delegation
        chains

  7.2.  Multi-Hop Delegation Chains

     In multi-agent systems, credentials may flow through delegation
     chains: User to Agent A to Agent B to Agent C.  At each hop,
     credentials SHOULD be attenuated — narrowing the scope, reducing the
     time-to-live, and lowering the rate limit.

     Each delegation hop MUST:

     *  Verify the delegating agent has the agent:delegate permission in
        VAIP

     *  Produce a signed delegation receipt (Ed25519 JWS) linking the
        delegator's agent_id to the delegate's agent_id

     *  Record the delegation as an audit event with event_type
        "credential_delegation"

     *  Enforce that the delegated credential's scope is a subset of the
        delegator's scope






  Nyantakyi                Expires 12 October 2026               [Page 11]


  Internet-Draft                    VAIP                        April 2026


  7.3.  Ephemeral Agent Identity

     For short-lived agents that do not require persistent identity
     registration, a future extension MAY support ephemeral identity using
     W3C did:key format.  Ephemeral agents would:

     *  Bootstrap identity on instantiation without pre-registration

     *  Receive a temporary VAIP agent_id linked to the did:key

     *  Have a maximum lifetime (RECOMMENDED: 24 hours)

     *  Still produce audit events attributable to the ephemeral identity

     *  Be subject to all VAIP permission checks

     Ephemeral identity is OPTIONAL and does not replace persistent
     Ed25519 identity for production agents requiring long-term
     accountability.

  7.4.  Integration with Credential Delegation Protocols

     VAIP is designed to be complementary to credential delegation
     protocols such as draft-sweeney-wimse-credential-delegation-00.  The
     integration model is:

     *  VAIP provides the agent identity layer (who is this agent?)

     *  VAIP provides the permission layer (what is it allowed to do?)

     *  VAIP provides the audit layer (what did it do?)

     *  A credential delegation protocol provides the credential flow (how
        does the agent safely access third-party services?)

     Together, these two layers cover the full agent security surface:
     identity, permissions, credentials, audit, and trust.

  8.  Security Considerations

  8.1.  Cryptographic Choices

            +================+===========+========================+
            | Primitive      | Algorithm | Rationale              |
            +================+===========+========================+
            | Agent identity | Ed25519   | Fast, compact, timing- |
            |                |           | attack resistant       |
            +----------------+-----------+------------------------+



  Nyantakyi                Expires 12 October 2026               [Page 12]


  Internet-Draft                    VAIP                        April 2026


            | Fingerprints   | SHA-256   | Widely supported,      |
            |                |           | collision resistant    |
            +----------------+-----------+------------------------+
            | Audit          | SHA-256   | Industry standard for  |
            | integrity      |           | data integrity         |
            +----------------+-----------+------------------------+
            | Password       | bcrypt    | Memory-hard,           |
            | hashing        | (cost 12) | adjustable work factor |
            +----------------+-----------+------------------------+
            | API key        | SHA-256   | One-way hashing for    |
            | storage        |           | stored secrets         |
            +----------------+-----------+------------------------+

                                    Table 2

  8.2.  Private Key Handling

     Conforming implementations:

     *  MUST generate private keys server-side using a cryptographic
        random number generator

     *  MUST return the private key to the operator exactly once

     *  MUST NOT store, log, or persist the private key after returning it

     *  MUST NOT transmit private keys over unencrypted channels

  8.3.  Multi-Tenant Isolation

     All database queries MUST be scoped to the authenticated
     organisation's identifier.  No agent, permission, or audit record
     from one organisation may be accessible by another.

  8.4.  Transport Security

     All API communications MUST use TLS 1.2 or higher.  TLS 1.3 is
     RECOMMENDED.

  8.5.  Threat Model

       +=====================+========================================+
       | Threat              | Mitigation                             |
       +=====================+========================================+
       | Key compromise      | Immediate revocation, new registration |
       +---------------------+----------------------------------------+
       | Audit tampering     | SHA-256 manifest, append-only storage  |
       +---------------------+----------------------------------------+



  Nyantakyi                Expires 12 October 2026               [Page 13]


  Internet-Draft                    VAIP                        April 2026


       | Cross-tenant access | Organisation-scoped queries            |
       +---------------------+----------------------------------------+
       | Replay attacks      | Time-sortable event IDs, timestamp     |
       |                     | validation                             |
       +---------------------+----------------------------------------+
       | Brute-force auth    | bcrypt hashing, API key entropy (192   |
       |                     | bits)                                  |
       +---------------------+----------------------------------------+
       | Trust manipulation  | Score from audited behaviour, not      |
       |                     | self-reported                          |
       +---------------------+----------------------------------------+

                                   Table 3

  9.  IANA Considerations

     This document requests the registration of the following media type:

     Type name  application

     Subtype name  vaip+json

     Required parameters  none

     Optional parameters  none

     Encoding considerations  binary (UTF-8 JSON)

     Security considerations  See the Security Considerations section of
        this document.

     Interoperability considerations  Implementations MUST support JSON
        encoding as defined in RFC 8259.

     Published specification  This document.

     Applications that use this media type  AI agent identity management
        systems, audit trail systems, trust verification services.

  10.  References

  10.1.  Normative References

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





  Nyantakyi                Expires 12 October 2026               [Page 14]


  Internet-Draft                    VAIP                        April 2026


     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032, January 2017,
                <https://www.rfc-editor.org/info/rfc8032>.

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

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", RFC 8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

  10.2.  Informative References

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, May 2008,
                <https://www.rfc-editor.org/info/rfc5280>.

     [I-D.sweeney-wimse-credential-delegation]
                Sweeney, D., "Credential Delegation Protocol for AI
                Agents", Work in Progress, Internet-Draft, draft-sweeney-
                wimse-credential-delegation-00, 2026,
                <https://datatracker.ietf.org/doc/html/draft-sweeney-
                wimse-credential-delegation-00>.

  Appendix A.  Reference Implementation

     A reference implementation of VAIP is available at:

     *  TypeScript SDK: https://www.npmjs.com/package/@vorim/sdk

     *  Python SDK: https://pypi.org/project/vorim/

     *  Protocol specification: https://github.com/Kzino/vorim-protocol

     *  MCP Server: https://www.npmjs.com/package/@vorim/mcp-server

  Appendix B.  Relationship to Existing Standards

     VAIP is designed to complement, not replace, existing identity and
     security standards:




  Nyantakyi                Expires 12 October 2026               [Page 15]


  Internet-Draft                    VAIP                        April 2026


     OAuth 2.0 (RFC 6749)  OAuth focuses on delegated authorisation for
        human users.  VAIP extends the concept to autonomous agents that
        act independently without human-in-the-loop authorisation.

     W3C Decentralized Identifiers (DID)  VAIP agent identifiers could be
        extended to DID format for decentralised resolution.  The current
        format prioritises simplicity and readability.

     SPIFFE  SPIFFE provides workload identity attestation.  VAIP adds
        trust scoring, audit trails, and permission models beyond
        identity.

     X.509 (RFC 5280)  VAIP uses Ed25519 directly rather than certificate
        chains, prioritising simplicity and agent-specific semantics over
        PKI hierarchies.

     Credential Delegation Protocol (draft-sweeney-wimse-credential-
     delegation-00)  The Credential Delegation Protocol defines secure
        OAuth token delegation across multi-agent systems.  VAIP is
        complementary: VAIP provides the identity, permission, and audit
        layers while the Credential Delegation Protocol provides the
        credential flow mechanics.  Together they cover the full agent
        security surface.  See Section 8 of this document for the
        integration model.

     WIMSE (Workload Identity in Multi-System Environments)  The IETF
        WIMSE working group addresses non-human identity in distributed
        systems.  VAIP's agent identity model is a specific application of
        workload identity to autonomous AI agents, with the addition of
        trust scoring, behavioural audit trails, and AI-specific
        permission scopes.

  Appendix C.  Regulatory Alignment

     VAIP's identity, permission, and audit features support compliance
     with emerging AI governance frameworks including:

     *  EU AI Act (enforced August 2025): Traceability and audit trail
        requirements for high-risk AI systems.

     *  US Executive Order on AI (EO 14110): Risk management,
        transparency, and accountability for AI systems.

     *  Colorado AI Act: Automated decision-making documentation
        requirements.

     *  NIST AI Risk Management Framework: AI system governance and
        accountability controls.



  Nyantakyi                Expires 12 October 2026               [Page 16]


  Internet-Draft                    VAIP                        April 2026


  Appendix D.  Acknowledgements

     The author thanks the open-source community and early adopters of the
     Vorim Agent Identity Protocol for their feedback and contributions to
     this specification.

  Author's Address

     Kwame Nyantakyi
     Vorim AI
     Email: kwame@vorim.ai
     URI:   https://vorim.ai







































  Nyantakyi                Expires 12 October 2026               [Page 17]


name: draft-singla-agent-identity-protocol
rev: 02
title: Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents
time: 2026-05-13T22:03:27Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-14T22:03:27Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-05-22T09:24:41.698331+00:00
source: ietf
abstract:
  The Agent Identity Protocol (AIP) defines a decentralized identity,
     delegation, and authorization framework for autonomous AI agents.
     AIP combines W3C Decentralized Identifiers (DIDs), capability-based
     authorization, cryptographic delegation chains, and deterministic
     validation to enable secure, auditable multi-agent workflows without
     relying on centralized identity providers.

full_text:
  Network Working Group                                          P. Singla
  Internet-Draft                                               Independent
  Intended status: Standards Track                             14 May 2026
  Expires: 15 November 2026


  Agent Identity Protocol (AIP): Decentralized Identity and Delegation for
                                 AI Agents
                  draft-singla-agent-identity-protocol-02

  Abstract

     The Agent Identity Protocol (AIP) defines a decentralized identity,
     delegation, and authorization framework for autonomous AI agents.
     AIP combines W3C Decentralized Identifiers (DIDs), capability-based
     authorization, cryptographic delegation chains, and deterministic
     validation to enable secure, auditable multi-agent workflows without
     relying on centralized identity providers.

  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 15 November 2026.

  Copyright Notice

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











  Singla                  Expires 15 November 2026                [Page 1]


  Internet-Draft                     AIP                          May 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  . . . . . . . . . . . . . . . . . . . . . . . .   7
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   7
       1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   7
       1.3.  Architecture Layers . . . . . . . . . . . . . . . . . . .   9
     2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .  10
       2.1.  Canonical JSON Serialization  . . . . . . . . . . . . . .  10
     3.  Definitions and Terminology . . . . . . . . . . . . . . . . .  11
       3.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .  15
       3.2.  Architecture Tiers  . . . . . . . . . . . . . . . . . . .  16
     4.  Core Identity (did:aip) . . . . . . . . . . . . . . . . . . .  17
       4.1.  AID Syntax  . . . . . . . . . . . . . . . . . . . . . . .  17
       4.2.  AID Derivation  . . . . . . . . . . . . . . . . . . . . .  17
       4.3.  AIP Namespace Catalog . . . . . . . . . . . . . . . . . .  18
       4.4.  Agent Identity Object Schema  . . . . . . . . . . . . . .  18
       4.5.  Uniqueness and Immutability . . . . . . . . . . . . . . .  19
     5.  Resource Model and Data Structures  . . . . . . . . . . . . .  19
       5.1.  Resource Naming . . . . . . . . . . . . . . . . . . . . .  19
       5.2.  Agent Identity Object . . . . . . . . . . . . . . . . . .  20
       5.3.  Capability Manifest . . . . . . . . . . . . . . . . . . .  22
       5.4.  Credential Token  . . . . . . . . . . . . . . . . . . . .  23
         5.4.1.  Step Execution Token  . . . . . . . . . . . . . . . .  25
       5.5.  Principal Token . . . . . . . . . . . . . . . . . . . . .  28
       5.6.  Registration Envelope . . . . . . . . . . . . . . . . . .  31
       5.7.  Revocation Object . . . . . . . . . . . . . . . . . . . .  33
       5.8.  Endorsement Object  . . . . . . . . . . . . . . . . . . .  36
       5.9.  Field Constraints and Catalog-Bound Scope Identifiers . .  37
       5.10. Delegation Rules  . . . . . . . . . . . . . . . . . . . .  39
       5.11. Capability Overlays . . . . . . . . . . . . . . . . . . .  39
       5.12. Engagement Objects  . . . . . . . . . . . . . . . . . . .  43
     6.  Registration Protocol . . . . . . . . . . . . . . . . . . . .  46
       6.1.  Envelope Submission . . . . . . . . . . . . . . . . . . .  46
       6.2.  Registration Validation . . . . . . . . . . . . . . . . .  46
       6.3.  Error Responses . . . . . . . . . . . . . . . . . . . . .  50
     7.  Agent Resolution  . . . . . . . . . . . . . . . . . . . . . .  50
       7.1.  DID Resolution  . . . . . . . . . . . . . . . . . . . . .  50
       7.2.  did:aip Method Resolution . . . . . . . . . . . . . . . .  51
       7.3.  DID Document Structure  . . . . . . . . . . . . . . . . .  53



  Singla                  Expires 15 November 2026                [Page 2]


  Internet-Draft                     AIP                          May 2026


       7.4.  Registry Genesis  . . . . . . . . . . . . . . . . . . . .  54
         7.4.1.  Key Generation  . . . . . . . . . . . . . . . . . . .  54
         7.4.2.  Registry ID Establishment . . . . . . . . . . . . . .  54
         7.4.3.  Self-Registration Exemption . . . . . . . . . . . . .  55
         7.4.4.  Registry Metadata Publication . . . . . . . . . . . .  55
         7.4.5.  Registry Trust Record . . . . . . . . . . . . . . . .  58
         7.4.6.  Single-Instance Constraint  . . . . . . . . . . . . .  60
         7.4.7.  Registry Key Rotation . . . . . . . . . . . . . . . .  60
       7.5.  AIP Gateway Protected Resource Metadata . . . . . . . . .  62
     8.  Credential Tokens . . . . . . . . . . . . . . . . . . . . . .  64
       8.1.  Credential Token Transport and Version Header . . . . . .  64
       8.2.  Token Issuance  . . . . . . . . . . . . . . . . . . . . .  65
         8.2.1.  Token Cache Requirements for Stateless Deployments  .  66
       8.3.  Token Refresh and Long-Running Tasks  . . . . . . . . . .  67
         8.3.1.  Agent Self-Refresh  . . . . . . . . . . . . . . . . .  67
         8.3.2.  Pre-emptive Refresh Requirements  . . . . . . . . . .  68
         8.3.3.  Delegation Chain Expiry . . . . . . . . . . . . . . .  69
         8.3.4.  Interaction with Approval Envelopes . . . . . . . . .  69
       8.4.  Token Exchange for MCP  . . . . . . . . . . . . . . . . .  70
         8.4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  70
         8.4.2.  Exchange Request  . . . . . . . . . . . . . . . . . .  70
         8.4.3.  Exchange Validation . . . . . . . . . . . . . . . . .  71
         8.4.4.  Exchange Response . . . . . . . . . . . . . . . . . .  72
         8.4.5.  Enterprise IdP Federation Profile . . . . . . . . . .  72
     9.  Credential and Step Execution Token Validation  . . . . . . .  76
       9.1.  Step 1: Parse . . . . . . . . . . . . . . . . . . . . . .  78
       9.2.  Step 2: Header Validation . . . . . . . . . . . . . . . .  78
       9.3.  Step 2a: Expiration Preflight . . . . . . . . . . . . . .  79
       9.4.  Step 3: Identify Agent and Retrieve Public Key  . . . . .  79
       9.5.  Step 4: Verify Signature  . . . . . . . . . . . . . . . .  79
       9.6.  Step 5: Validate Claims . . . . . . . . . . . . . . . . .  80
         9.6.1.  Step 5a: iat (Issued-At Time) . . . . . . . . . . . .  80
         9.6.2.  Step 5b: exp (Expiration Time)  . . . . . . . . . . .  80
         9.6.3.  Step 5c: Token Not Expired  . . . . . . . . . . . . .  80
         9.6.4.  Step 5d: aud (Audience) . . . . . . . . . . . . . . .  80
         9.6.5.  Step 5e: jti (JWT ID) Replay Check  . . . . . . . . .  80
         9.6.6.  Step 5f: aip_version  . . . . . . . . . . . . . . . .  81
         9.6.7.  Step 5g: Issuer and Subject Binding . . . . . . . . .  81
       9.7.  Step 6: TTL Validation  . . . . . . . . . . . . . . . . .  81
       9.8.  Step 6a: Registry Trust Anchoring (Conditional) . . . . .  82
       9.9.  Step 6b: Engagement Validation (Conditional)  . . . . . .  83
       9.10. Step 7: Revocation Check  . . . . . . . . . . . . . . . .  83
       9.11. Step 8: Delegation Chain Validation . . . . . . . . . . .  84
         9.11.1.  Step 8 Post-Check A  . . . . . . . . . . . . . . . .  87
         9.11.2.  Step 8 Post-Check B  . . . . . . . . . . . . . . . .  87
         9.11.3.  Step 8 Post-Check C: Identity Proofing . . . . . . .  87
       9.12. Step 9: Capability Validation . . . . . . . . . . . . . .  88
       9.13. Step 9a: Scope Verification . . . . . . . . . . . . . . .  88



  Singla                  Expires 15 November 2026                [Page 3]


  Internet-Draft                     AIP                          May 2026


       9.14. Step 9b: Capability Overlay (Conditional) . . . . . . . .  89
       9.15. Step 9c: Delegation Scope Inheritance . . . . . . . . . .  89
       9.16. Step 9d: Grant Tier Conformance . . . . . . . . . . . . .  90
       9.17. Step 10: DPoP Validation (Conditional)  . . . . . . . . .  90
       9.18. Step 10a: Approval Envelope Step Verification
              (Conditional)  . . . . . . . . . . . . . . . . . . . . .  92
       9.19. Step 11: Tier 3 Enterprise Checks (Conditional) . . . . .  93
       9.20. Step 12: Accept . . . . . . . . . . . . . . . . . . . . .  94
       9.21. Step Execution Token Validation Profile . . . . . . . . .  94
     10. Delegation  . . . . . . . . . . . . . . . . . . . . . . . . .  96
       10.1.  Delegation Chain . . . . . . . . . . . . . . . . . . . .  96
       10.2.  Capability Scope Rules . . . . . . . . . . . . . . . . .  97
       10.3.  Delegation Validation  . . . . . . . . . . . . . . . . .  98
       10.4.  Delegated Identity Chaining for A2A Workflows  . . . . .  99
     11. Revocation Management . . . . . . . . . . . . . . . . . . . . 100
       11.1.  Revocation Object  . . . . . . . . . . . . . . . . . . . 100
       11.2.  Revocation Submission Validation . . . . . . . . . . . . 101
       11.3.  Certificate Revocation List (CRL)  . . . . . . . . . . . 102
       11.4.  Revocation Checking  . . . . . . . . . . . . . . . . . . 104
       11.5.  Registry Push Notification Protocol (RPNP) . . . . . . . 105
         11.5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . 105
         11.5.2.  Subscription . . . . . . . . . . . . . . . . . . . . 105
         11.5.3.  Push Event Payload . . . . . . . . . . . . . . . . . 108
         11.5.4.  Delivery Guarantees  . . . . . . . . . . . . . . . . 110
     12. Principal Grant Ceremony (AIP-GRANT)  . . . . . . . . . . . . 111
       12.1.  Overview and Roles . . . . . . . . . . . . . . . . . . . 111
       12.2.  GrantRequest Object  . . . . . . . . . . . . . . . . . . 112
       12.3.  Principal Wallet Consent Requirements  . . . . . . . . . 114
       12.4.  GrantResponse Object . . . . . . . . . . . . . . . . . . 118
       12.5.  Transport Bindings . . . . . . . . . . . . . . . . . . . 120
       12.6.  Sub-Agent Delegation Flow  . . . . . . . . . . . . . . . 120
       12.7.  AIP-GRANT Error Codes  . . . . . . . . . . . . . . . . . 121
       12.8.  G1: Registry-Mediated Grant Flow . . . . . . . . . . . . 121
       12.9.  G2: Direct Deployer Grant Flow . . . . . . . . . . . . . 123
       12.10. G3: Full Ceremony Grant Flow (OAuth 2.1) . . . . . . . . 124
     13. Approval Envelopes  . . . . . . . . . . . . . . . . . . . . . 127
       13.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . 127
       13.2.  The Token-Expiry-While-Pending Problem . . . . . . . . . 127
       13.3.  Approval Envelope Schema . . . . . . . . . . . . . . . . 127
       13.4.  Step Schema  . . . . . . . . . . . . . . . . . . . . . . 130
       13.5.  Compensation Step Schema . . . . . . . . . . . . . . . . 132
       13.6.  Approval Envelope Lifecycle  . . . . . . . . . . . . . . 133
       13.7.  Action Hash Computation  . . . . . . . . . . . . . . . . 135
       13.8.  Step Claim and Execution Protocol  . . . . . . . . . . . 136
       13.9.  SAGA Compensation Semantics  . . . . . . . . . . . . . . 139
       13.10. Approval Envelope Validation Rules . . . . . . . . . . . 140
     14. Reputation and Endorsements . . . . . . . . . . . . . . . . . 142
       14.1.  Endorsement Object . . . . . . . . . . . . . . . . . . . 142



  Singla                  Expires 15 November 2026                [Page 4]


  Internet-Draft                     AIP                          May 2026


         14.1.1.  Endorsement Acceptance Requirements  . . . . . . . . 143
       14.2.  Reputation Scoring . . . . . . . . . . . . . . . . . . . 143
     15. Lifecycle States  . . . . . . . . . . . . . . . . . . . . . . 144
     16. Principal Chain . . . . . . . . . . . . . . . . . . . . . . . 145
     17. Registry Interface  . . . . . . . . . . . . . . . . . . . . . 145
       17.1.  Endpoint Inventory . . . . . . . . . . . . . . . . . . . 146
       17.2.  AID URL Encoding . . . . . . . . . . . . . . . . . . . . 149
       17.3.  Response Format  . . . . . . . . . . . . . . . . . . . . 149
       17.4.  Agent Registration Metadata  . . . . . . . . . . . . . . 150
       17.5.  Agent Key Rotation Endpoint  . . . . . . . . . . . . . . 150
       17.6.  Agent Public-Key Endpoints . . . . . . . . . . . . . . . 152
       17.7.  Agent Capability Manifest Endpoint . . . . . . . . . . . 153
       17.8.  Agent Revocation Status Endpoint . . . . . . . . . . . . 153
       17.9.  Revocation Submission Endpoint . . . . . . . . . . . . . 154
       17.10. CRL Response . . . . . . . . . . . . . . . . . . . . . . 155
       17.11. Agent Heartbeat Endpoint . . . . . . . . . . . . . . . . 156
       17.12. Approval Envelope Endpoints  . . . . . . . . . . . . . . 156
       17.13. Resource Registration  . . . . . . . . . . . . . . . . . 159
       17.14. OAuth 2.1 Authorization Server . . . . . . . . . . . . . 160
         17.14.1.  Registry Metadata Additions . . . . . . . . . . . . 161
       17.15. AIP Catalog Sync, Scope Map, and Namespace Map . . . . . 163
       17.16. Capability Overlay Endpoints . . . . . . . . . . . . . . 167
       17.17. Engagement Endpoints . . . . . . . . . . . . . . . . . . 168
       17.18. RPNP Subscription Endpoints  . . . . . . . . . . . . . . 169
       17.19. Key Management and Rotation  . . . . . . . . . . . . . . 170
       17.20. Pagination and Large Responses . . . . . . . . . . . . . 170
     18. Error Handling  . . . . . . . . . . . . . . . . . . . . . . . 170
       18.1.  Error Response Format  . . . . . . . . . . . . . . . . . 171
       18.2.  Standard Error Codes . . . . . . . . . . . . . . . . . . 172
       18.3.  Error Detail Types . . . . . . . . . . . . . . . . . . . 177
     19. Rate Limiting and Abuse Prevention  . . . . . . . . . . . . . 178
       19.1.  Rate Limit Response Format . . . . . . . . . . . . . . . 178
       19.2.  Per-Endpoint Rate Limit Categories . . . . . . . . . . . 179
         19.2.1.  Category R1 - Registration writes  . . . . . . . . . 179
         19.2.2.  Category R2 - Key rotation writes  . . . . . . . . . 180
         19.2.3.  Category R3 - Revocation writes  . . . . . . . . . . 180
         19.2.4.  Category R4 - Validation-driven key reads  . . . . . 180
         19.2.5.  Category R5 - CRL reads  . . . . . . . . . . . . . . 181
         19.2.6.  Category R6 - Endorsement writes . . . . . . . . . . 181
         19.2.7.  Category R7 - Approval Envelope writes and step
                 claims  . . . . . . . . . . . . . . . . . . . . . . . 181
       19.3.  Registration Abuse Prevention  . . . . . . . . . . . . . 181
         19.3.1.  AID uniqueness enforcement . . . . . . . . . . . . . 182
         19.3.2.  Principal delegation chain verification at
                 registration  . . . . . . . . . . . . . . . . . . . . 182
         19.3.3.  Registration flood from shared principals  . . . . . 182
         19.3.4.  Public Registry challenge for unauthenticated
                 deployers . . . . . . . . . . . . . . . . . . . . . . 182



  Singla                  Expires 15 November 2026                [Page 5]


  Internet-Draft                     AIP                          May 2026


       19.4.  Validation-Driven Lookup Limits  . . . . . . . . . . . . 183
         19.4.1.  Key version caching  . . . . . . . . . . . . . . . . 183
         19.4.2.  Historical key depth limit . . . . . . . . . . . . . 183
         19.4.3.  kid validation at the Relying Party  . . . . . . . . 183
       19.5.  Approval Envelope Rate Limits  . . . . . . . . . . . . . 183
         19.5.1.  Envelope submission rate . . . . . . . . . . . . . . 183
         19.5.2.  Pending envelope limit . . . . . . . . . . . . . . . 183
         19.5.3.  Step claim timeout . . . . . . . . . . . . . . . . . 184
         19.5.4.  Compensation cascade depth . . . . . . . . . . . . . 184
       19.6.  Graduated Backoff Requirements . . . . . . . . . . . . . 184
       19.7.  Historical Key Retention Requirements  . . . . . . . . . 185
     20. Versioning and Compatibility  . . . . . . . . . . . . . . . . 185
       20.1.  Tier Conformance . . . . . . . . . . . . . . . . . . . . 187
     21. Security Considerations . . . . . . . . . . . . . . . . . . . 188
       21.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . . 188
       21.2.  Cryptographic Requirements . . . . . . . . . . . . . . . 190
       21.3.  Proof-of-Possession (DPoP) . . . . . . . . . . . . . . . 191
       21.4.  Key Management . . . . . . . . . . . . . . . . . . . . . 194
       21.5.  Token Security . . . . . . . . . . . . . . . . . . . . . 196
       21.6.  Tier 3 mTLS Certificate Profile  . . . . . . . . . . . . 196
       21.7.  Delegation Chain Security  . . . . . . . . . . . . . . . 197
       21.8.  Registry Security  . . . . . . . . . . . . . . . . . . . 198
       21.9.  Revocation Security  . . . . . . . . . . . . . . . . . . 198
       21.10. Approval Envelope Security . . . . . . . . . . . . . . . 199
       21.11. Privacy Considerations . . . . . . . . . . . . . . . . . 199
     22. JSON Schema and Catalog Artifact Index  . . . . . . . . . . . 199
     23. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 202
       23.1.  Common Requirements  . . . . . . . . . . . . . . . . . . 202
       23.2.  Conformance Classes  . . . . . . . . . . . . . . . . . . 202
       23.3.  Optional Feature Profiles  . . . . . . . . . . . . . . . 205
       23.4.  Conformance Testing Methodology  . . . . . . . . . . . . 207
       23.5.  Conformance Claim Content  . . . . . . . . . . . . . . . 208
     24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 208
       24.1.  Non-IANA DID Method Registry . . . . . . . . . . . . . . 208
       24.2.  Existing HTTP and Discovery Registrations  . . . . . . . 210
       24.3.  AIP Scope Identifiers  . . . . . . . . . . . . . . . . . 210
       24.4.  AID Namespace Catalog  . . . . . . . . . . . . . . . . . 210
       24.5.  AIP Grant Tier Values  . . . . . . . . . . . . . . . . . 210
       24.6.  AIP Error Codes  . . . . . . . . . . . . . . . . . . . . 211
       24.7.  Media Types  . . . . . . . . . . . . . . . . . . . . . . 217
         24.7.1.  application/aip+jwt  . . . . . . . . . . . . . . . . 217
         24.7.2.  application/aip-set+jwt  . . . . . . . . . . . . . . 218
         24.7.3.  application/aip-crl+json . . . . . . . . . . . . . . 219
     25. Normative References  . . . . . . . . . . . . . . . . . . . . 221
     26. Informative References  . . . . . . . . . . . . . . . . . . . 223
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 224
     Appendix A: Implementation Considerations (Non-Normative) . . . . 224
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 225



  Singla                  Expires 15 November 2026                [Page 6]


  Internet-Draft                     AIP                          May 2026


  1.  Introduction

     Autonomous AI agents are deployed in production environments to act
     on behalf of human and organisational principals.  An agent may send
     emails, book appointments, make purchases, access file systems, spawn
     child agents to complete subtasks, and communicate across multiple
     platforms, all without explicit human approval for each action.

     This creates an identity gap.  When an agent presents itself to an
     API, a payment processor, or another agent, there is no standard
     mechanism to establish: the agent's persistent identity across
     interactions; the human or organisation on whose authority it acts;
     the specific actions it is permitted to take; whether it has been
     compromised or revoked; or whether it has a trustworthy history.

     AIP addresses this gap.  It is designed as neutral, open
     infrastructure analogous to HTTP, OAuth, and JWT, providing
     infrastructure that any application can build on without vendor
     dependency.

  1.1.  Motivation

     The absence of an identity standard creates concrete operational
     problems.  Services cannot implement fine-grained agent access
     control.  Humans have no auditable record of what their agents did.
     Compromised agents cannot be reliably stopped.  Agent-to-agent
     systems have no basis for trust.

     Existing deployments typically operate in one of two modes: no
     access, or full access.  AIP introduces fine-grained capability
     declarations.  A principal can grant email.read without email.send,
     or transactions with a max_daily_total constraint.

  1.2.  Design Philosophy

     AIP is built on the following design principles and relationships:

     Neutral and open.  This document is submitted under BCP 78, BCP 79,
     and the IETF Trust Legal Provisions.  Code Components extracted from
     this document are licensed under the Revised BSD License as described
     in those Legal Provisions.  This document defines the did:aip DID
     method and requests its registration with the W3C DID Method
     Registry.

     Build on existing standards.  AIP builds on W3C DID, JWT [RFC7519],
     JWK [RFC7517], DPoP [RFC9449], and CRL patterns from [RFC5280].





  Singla                  Expires 15 November 2026                [Page 7]


  Internet-Draft                     AIP                          May 2026


     Human sovereignty.  Every agent action must trace to a human or
     authorised organisational principal.

     Security proportional to risk.  AIP defines three security tiers
     matching overhead to risk level.

     Deterministic verification.  The Validation Algorithm (Section 9) is
     fully deterministic: two independent implementations executing the
     same steps on the same token will reach the same result.

     Zero Trust Architecture.  AIP is designed to support the zero trust
     principles defined in [SP-800-207] and to provide protocol controls
     that can be used by deployments seeking alignment with NIST SP
     800-63-4 [SP-800-63-4] AAL2 for agent-to-service interactions.  This
     specification does not by itself assert SP 800-63-4 conformance,
     certification, or audit sufficiency.  Any implementation claiming SP
     800-63-4 or AAL2 conformance MUST maintain a separate conformance
     mapping covering its concrete authenticators, identity proofing
     process, verifier behavior, key management, logging, and operational
     controls.  No agent is implicitly trusted by virtue of its origin,
     network location, or prior successful interaction.  Every interaction
     MUST execute the validation algorithm in Section 9; Registry-
     dependent checks are performed according to the token's Tier,
     revocation-checking mode, and cache rules.  Short-lived Credential
     Tokens bound by a mandatory TTL limit the blast radius of any
     credential compromise.  Revocation is checked in real time for Tier 2
     sensitive operations as specified in Section 11.4.  DPoP proof-of-
     possession (Section 21.3) ensures that possession of a valid
     Credential Token is insufficient for impersonation without the
     corresponding private key material, supporting the anti-replay
     objectives of [SP-800-207] Section 3.

     Least Privilege.  Agents are granted only the specific capabilities
     required for their declared purpose, expressed as signed Capability
     Manifests (Section 5.3).  Capability grants are always additive from
     principal to agent and never exceed the principal-approved capability
     set or, for delegated agents, the delegating parent's effective
     Capability Manifest.  A child agent must not be granted capabilities
     that the delegating parent does not itself hold (Rule D-1,
     Section 5.10).  The max_delegation_depth field (Section 10) bounds
     the depth of sub-agent hierarchies, limiting transitive capability
     propagation.  Capability constraints allow fine-grained least-
     privilege expression within each capability category, consistent with
     [SP-800-207] Section 3 (Tenets 5 and 6).

     Relationship to SPIFFE/SPIRE.  SPIFFE is designed for workload
     identity within enumerable, infrastructure-managed environments.  AIP
     is designed for autonomous agents that are created dynamically,



  Singla                  Expires 15 November 2026                [Page 8]


  Internet-Draft                     AIP                          May 2026


     operate across organisational boundaries, and act on behalf of named
     human principals whose authority must be cryptographically traceable.
     An enterprise may deploy SPIFFE for its internal service mesh and AIP
     for its agent fleet without conflict.  The two mechanisms are
     complementary and operate at distinct layers of the identity stack.

     Relationship to MCP.  The Model Context Protocol [MCP] defines how AI
     agents discover and invoke tools and data sources.  AIP is the agent
     identity layer that sits beneath MCP's authorisation flow: AIP
     establishes that an agent is who it claims to be (identification via
     Credential Token), that it was authorised by a named human principal
     (delegation chain in the Principal Token), and that it holds specific
     capabilities (Capability Manifest).  AIP does not replace MCP's tool-
     access OAuth flow - it provides the agent identity that OAuth's "sub"
     claim cannot supply when the subject is an autonomous agent rather
     than a human user.  An AIP-authenticated agent can obtain scoped
     access tokens for MCP servers via the token exchange mechanism
     defined in Section 8.4 and the OAuth 2.1 Authorization Server profile
     in Section 17.14.

     Out of scope - Prompt injection prevention.  AIP is an identity and
     authorisation protocol.  Whether the content an agent processes
     contains adversarial instructions is an application-layer and model-
     layer concern outside this specification's scope.  AIP mitigates the
     persistence window of a successful prompt injection attack: a
     compromised agent may be revoked via full_revoke (Section 11.1).
     Tier 2 and Tier 3 revocation checks fail closed against live Registry
     state; Tier 1 rejection is bounded by the CRL freshness SLA, while
     child materialisation and replica convergence are bounded by the
     revocation propagation requirements in Section 11.  AIP does not
     prevent the initial injection - it limits the attacker's persistence.

  1.3.  Architecture Layers

     AIP is structured as six ordered layers:
















  Singla                  Expires 15 November 2026                [Page 9]


  Internet-Draft                     AIP                          May 2026


      +------------------------------------------------------+
      | Layer 6 - Reputation Trust over time                 |
      +------------------------------------------------------+
      | Layer 5 - Revocation Standard kill switch            |
      +------------------------------------------------------+
      | Layer 4 - Credential Token & Verification            |
      |           Cryptographic proof                        |
      +------------------------------------------------------+
      | Layer 3 - Capabilities What the agent can do         |
      +------------------------------------------------------+
      | Layer 2 - Principal Chain Who authorised it          |
      |           incl. AIP-GRANT and Approval Envelopes     |
      +------------------------------------------------------+
      | Layer 1 - Core Identity Who the agent IS             |
      +------------------------------------------------------+

                       Figure 1: AIP Architecture Layers

  2.  Conventions

     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 "MUST" in preference to "SHALL" throughout for
     consistency.  Where earlier drafts used "SHALL", the normative force
     is identical; the term has been normalised to "MUST" per this
     convention.

     JSON is used throughout this document as defined in [RFC8259].  URIs
     are used as defined in [RFC3986].  ABNF notation is used as defined
     in [RFC5234], including its core rules (ALPHA, DIGIT, HEXDIG, SP, and
     the other rules in RFC5234 Appendix B.1).  HTTP status codes,
     headers, and semantics are as defined in [RFC9110].

     All Ed25519 signatures are computed per [RFC8032].  DPoP proofs are
     constructed per [RFC9449].

  2.1.  Canonical JSON Serialization

     Several objects in this specification are signed outside the JWT
     framework.  For those objects, AIP first constructs the object-
     specific signing input described below, then serializes that signing
     input with the JSON Canonicalization Scheme (JCS) defined in
     [RFC8785].  The following procedure MUST be used when computing or
     verifying signatures, and when computing Action Hashes:



  Singla                  Expires 15 November 2026               [Page 10]


  Internet-Draft                     AIP                          May 2026


     1  Represent the object as a JSON value per [RFC8259].

     2  Before computing any signature, set the object's "signature" field
        to the empty string "".  The "signature" field MUST be included in
        the serialisation at its lexicographically correct position with
        value "".

     3  Serialize the resulting signing-input JSON value using JCS
        [RFC8785].  Array element order MUST be preserved; arrays MUST NOT
        be sorted.

     4  Encode the JCS result as a UTF-8 byte sequence with no BOM.

     Every object type signed with this procedure MUST define a top-level
     signature member in its schema or in the object-specific signing
     profile.  If an unsigned object instance is being prepared for
     signing and the top-level signature member is absent, the signer MUST
     inject that member with value "" before canonicalization.  Verifiers
     MUST reconstruct the same signing input by replacing the received
     signature value with "".  Object types that do not define a signature
     member MUST NOT be signed with this procedure unless a later profile
     explicitly defines the signature member name and signing input.

     The serialization step is JCS.  The preceding signature-field
     replacement or injection is AIP-specific signing-input normalization
     and is not part of RFC 8785 itself.  Implementations SHOULD use an
     RFC8785-conformant library to ensure serialization correctness.  When
     this procedure is used to compute Action Hashes, implementations MUST
     use an RFC8785-conformant library; custom serializer implementations
     MUST NOT be used for that purpose.

     EXAMPLE (informative):

      {"z": 1, "a": 2, "m": [3,1,2]}  →  {"a":2,"m":[3,1,2],"z":1}

     This canonical serialization procedure applies to Capability
     Manifests, Agent Identity Objects, Revocation Objects, Endorsement
     Objects, GrantRequest Objects when signed, and Approval Envelopes.
     It MUST NOT be used for JWT-format objects, including Credential
     Tokens, Principal Tokens, Step Execution Tokens, and RPNP push
     notifications.  JWT-format objects MUST use standard JWS compact
     serialization per [RFC7515].

  3.  Definitions and Terminology

     The following terms are used throughout this specification:

     Agent:  An autonomous software system powered by a large language



  Singla                  Expires 15 November 2026               [Page 11]


  Internet-Draft                     AIP                          May 2026


        model that can perceive inputs, reason about them, and execute
        actions in the world on behalf of a principal.

     Agent Identity Descriptor (AID):  A cryptographically derived,
        persistent identifier for an agent conforming to the did:aip DID
        method defined in Section 4.1.  An AID is a W3C DID.  A standalone
        did:aip string does not encode its authoritative Registry;
        resolution requires Registry context as defined in Section 7.

     Decentralized Identifier (DID):  A W3C Decentralized Identifier.  DID
        Documents, DID URLs, and DID resolution are used as defined by W3C
        DID Core.

     Production Deployment:  Any AIP Registry or Relying Party deployment
        where more than one process, container, or server instance may
        validate tokens for the same AID simultaneously, or where the
        deployment serves external principals not under the operator's
        direct control.  Deployments that are explicitly single-instance
        and serve only internal development or testing purposes are not
        production deployments for the purposes of Section 8.2.1.

     Principal:  The human or organisational entity on whose authority an
        agent acts.  Every AIP delegation chain MUST have a verifiable
        principal at its root.  Principals are identified by W3C DIDs, but
        NOT by did:aip (which is reserved for agents).

     Agent Deployer:  The party that provisions an agent on behalf of a
        principal.  May be the principal themselves or a service acting
        with the principal's explicit consent.

     Principal Wallet:  Software that holds the principal's DID private
        key and implements the AIP-GRANT consent and signing ceremony.
        Throughout this document, Principal Wallet references use this
        capitalized term unless the context explicitly describes a generic
        wallet ecosystem.

     Capability Manifest:  A versioned, signed JSON document stored in the
        Registry that declares the specific permissions (scopes and
        constraints) granted to an agent.  Defined in Section 5.3.

     Credential Token:  A signed JWT-format token presented by an agent to
        a Relying Party as proof of identity and authorisation for a
        specific interaction.  Defined in Section 8.1.

     Step Execution Token (SET):  A short-lived Registry-issued JWT,






  Singla                  Expires 15 November 2026               [Page 12]


  Internet-Draft                     AIP                          May 2026


        distinct from an agent-issued Credential Token, attesting that a
        specific Approval Envelope step has been claimed by its designated
        actor.  Defined in Section 13.8 and validated using the Step
        Execution Token profile in Section 9.

     Principal Token:  A signed JWT payload encoding one delegation link
        in the AIP principal chain.  Principal Tokens are embedded as
        compact-serialised JWTs in the aip_chain array of a Credential
        Token or Step Execution Token.  Defined in Section 5.5.

     Relying Party (RP):  Any service, API, or agent that receives and
        verifies an AIP Credential Token or Step Execution Token.
        Responsible for implementing the Validation Algorithm (Section 9).

     Authorization Server (AS):  The OAuth 2.1 authorization server role.
        In G3 grant flows, the Registry commonly acts as the AS for
        authorization-code and token endpoints.

     Delegation:  The act of granting a subset of capabilities from a
        principal or parent agent to a child agent.  Formally expressed as
        a Principal Token in the delegation chain.

     Delegation Depth:  A non-negative integer counter incremented at each
        delegation step.  An agent directly authorised by the root
        principal has delegation depth 0.  A child agent of that agent has
        delegation depth 1, and so on.

     Tier:  An operation security classification derived from the highest-
        risk requested scope in the synced AIP Scope Catalog.  Tier
        determines the applicable revocation-checking mode, maximum
        Credential Token lifetime, and mandatory security mechanisms.
        Three Tiers are defined in Section 3.2.  Tier selection on
        performance or availability grounds alone, without using the
        synced catalog metadata, is a misconfiguration and a violation of
        AIP's zero-trust model.

     Grant Tier:  One of three standardised AIP-GRANT ceremony profiles:
        G1 (Registry-Mediated), G2 (Direct Deployer), G3 (Full Ceremony).
        Defined in Section 12.  Grant Tier is a ceremony-assurance axis;
        it is distinct from the security Tier derived from an operation's
        requested scopes.

     Capability Overlay:  A Registry-stored, issuer-signed document that
        restricts an agent's effective capability set for a specific
        engagement or issuer context.  Defined in Section 5.11.

     Engagement Object:  A mutable Registry resource that models a multi-




  Singla                  Expires 15 November 2026               [Page 13]


  Internet-Draft                     AIP                          May 2026


        party engagement, serving as the parent container for Capability
        Overlays, Approval Envelopes, and participant rosters.  Defined in
        Section 5.12.

     Approval Envelope:  A signed document submitted to the Registry that
        pre-authorises a complete multi-step workflow in a single
        principal signing ceremony.  Decouples approval from execution.
        Defined in Section 13.

     Action Hash:  A SHA-256 hash of the canonical JSON representation of
        an approval step's action descriptor.  Binds approval to a
        specific operation.  Computed per Section 13.7.

     Registry:  The authoritative store and resolver for AIP agents,
        Capability Manifests, revocation state, and delegation chains.
        Implements the Registry Interface (Section 17) and the Validation
        Algorithm (Section 9).  May be operated by a principal, a service,
        or a consortium.

     AIP-GRANT:  The principal authorization protocol defining how
        principals authorize agents through a consent ceremony.  Defined
        in Section 12.

     Revocation Object:  A signed document declaring that an agent's grant
        is revoked, either in whole (full_revoke) or in part (scope_revoke
        or delegation_revoke).  Defined in Section 5.7.

     Certificate Revocation List (CRL):  An AIP signed JSON revocation
        artifact published by the Registry for Tier 1 bounded-staleness
        validation.  Tier 2 and Tier 3 validation use live Registry
        revocation status lookups; they do not satisfy their real-time
        revocation requirement by fetching an on-demand CRL.  Defined in
        Section 11.3.

     DPoP Proof:  A Demonstration of Proof-of-Possession as defined in
        [RFC9449].  Mandatory for Tier 2 and Tier 3 operations, and also
        mandatory for any Tier 1 scope or endpoint that explicitly
        requires DPoP.  Binds a Credential Token to a specific HTTP
        request and the agent's key material.

     Authentication Assurance Level 2 (AAL2):  A NIST SP 800-63 assurance
        level for authentication strength.  When this specification refers
        to AAL2, it means AAL2 as defined by the cited NIST SP 800-63
        document.

     JWK, JWS, and JWT:  JSON Web Key, JSON Web Signature, and JSON Web





  Singla                  Expires 15 November 2026               [Page 14]


  Internet-Draft                     AIP                          May 2026


        Token, respectively.  AIP uses JWK for public key representation,
        JWS compact serialization for signed JWTs, and JWT payloads for
        Credential Tokens, Principal Tokens, Step Execution Tokens, and
        RPNP push notifications.

     Lowercase Hexadecimal Encoding (LCHEX):  The lowercase hexadecimal
        representation of a byte string, using characters 0-9 and a-f
        only.

     Registry Push Notification Protocol (RPNP):  The optional Registry
        push protocol for revocation notifications, defined in
        Section 11.5.

     Enterprise Identity Provider (Enterprise IdP):  An OAuth 2.0/2.1 or
        OIDC-compliant authorization server operated by an enterprise
        organisation, such as Microsoft Entra ID, Okta, Ping Identity, or
        an equivalent system, that manages human principal identities,
        enforces enterprise access policies including Conditional Access
        and ABAC, and issues access tokens scoped to enterprise resources.
        In AIP, an Enterprise IdP is the authorization server that a
        Relying Party trusts for resource access tokens, distinct from the
        AIP Registry acting as an OAuth AS for AIP-scope token exchange.
        Registries identify an Enterprise IdP by the presence of the
        enterprise_idp_required flag on a registered resource record (see
        Section 8.4.5).

     Endorsement:  A signed statement affirming a positive experience or
        outcome of an interaction with an agent.  Contributes to the
        agent's reputation score.  Defined in Section 14.1.

  3.1.  Abbreviations

     The following common abbreviations are used with their ordinary
     industry meanings or with the referenced external specifications:

     ABAC  Attribute-Based Access Control.

     BOM  Byte Order Mark.  AIP canonical JSON signing input uses UTF-8
        without a leading BOM.

     CDN  Content Delivery Network.

     DAG  Directed Acyclic Graph.

     FIDO2/WebAuthn  FIDO2 and Web Authentication.

     HSM  Hardware Security Module.




  Singla                  Expires 15 November 2026               [Page 15]


  Internet-Draft                     AIP                          May 2026


     HMAC  Hash-based Message Authentication Code.

     JCS  JSON Canonicalization Scheme, defined by [RFC8785].

     JWKS  JSON Web Key Set, the JWK container format used by OAuth and
        OIDC providers to publish signing keys.

     MITM  Man-in-the-Middle.

     mTLS  Mutual TLS.

     OCSP  Online Certificate Status Protocol, defined by [RFC6960].

     PII  Personally Identifiable Information.

     PKCE  Proof Key for Code Exchange, defined by [RFC7636].

     SAGA  Distributed-workflow compensation pattern.

     SLA  Service-Level Agreement.

     TTL  Time To Live.

  3.2.  Architecture Tiers

     AIP defines three security Tiers that map synced AIP Scope Catalog
     metadata to mandatory protocol behaviors.  Tiers are NOT performance
     classes and are not locally chosen labels; they are derived from the
     highest-risk requested scope.

     *  *Tier 1 (Bounded-staleness):* Optimized for high availability and
        low latency.  Revocation is checked against a Registry-published
        CRL with a mandatory 15-minute update SLA.  Principals MAY use
        did:key for Tier 1 operations.

     *  *Tier 2 (Real-time):* The default Tier for sensitive operations.
        Revocation status MUST be checked in real-time against the
        Registry on every interaction.  DPoP proof-of-possession (RFC
        9449) is REQUIRED.  Principals MUST use did:web to enable Registry
        trust anchoring.

     *  *Tier 3 (Regulated/Enterprise):* The highest security level for
        regulated or high-value environments.  Tier 3 supplements Tier 2
        with mandatory mutual TLS (mTLS) and certificate revocation
        checking using OCSP or an equivalent deployment-profile mechanism
        defined in Section 21.6.





  Singla                  Expires 15 November 2026               [Page 16]


  Internet-Draft                     AIP                          May 2026


     The complete mapping of Tiers to normative protocol requirements is
     defined in the Tier Conformance Table in Section 20.1.

  4.  Core Identity (did:aip)

     Every AIP agent has a cryptographically derived, persistent
     identifier conforming to the W3C Decentralized Identifier (DID)
     standard [W3C-DID].  This document defines the AIP DID method did:aip
     and provides non-IANA W3C DID Method Registry registration
     information in Section 24.1.

  4.1.  AID Syntax

     An Agent Identity Descriptor (AID) conforms to the following ABNF:

             AID        = "did:aip:" namespace ":" agent-id
             namespace  = LOALPHA *( LOALPHA / DIGIT )
                          *( "-" 1*( LOALPHA / DIGIT ) )
             agent-id   = 32LOHEXDIG
             LOALPHA    = %x61-7A        ; a-z only, lowercase
             DIGIT      = %x30-39
             LOHEXDIG   = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
                                         ; lowercase hex digit only

     Example: did:aip:personal:9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3

     The namespace MUST begin with a lowercase alpha character, MUST NOT
     end with a hyphen, and MUST NOT contain consecutive hyphens.
     Implementations MUST reject AIDs containing uppercase hex digits or
     uppercase namespace characters.

     *  namespace: A lowercase alphanumeric string with optional single-
        hyphen-separated segments identifying the agent type.  Each hyphen
        MUST be followed by one or more lowercase alphanumeric characters.
        Concrete namespace registrations are maintained in the AIP
        Namespace Catalog (Section 17.15).

     *  agent-id: A 32-character hexadecimal string (lowercase) computed
        as the leftmost 128 bits (first 16 octets) of the SHA-256 hash of
        the agent's public Ed25519 key material (the JWK x value
        base64url-decoded).

  4.2.  AID Derivation

     An AID is derived deterministically from the agent's Ed25519 public
     key:

     1.  Generate an Ed25519 keypair per [RFC8032].



  Singla                  Expires 15 November 2026               [Page 17]


  Internet-Draft                     AIP                          May 2026


     2.  Encode the public key as a JWK with kty="OKP", crv="Ed25519", and
         the public key value in the x field (base64url-encoded).

     3.  Compute SHA-256(base64url_decode(x)) to obtain a 32-byte digest.

     4.  Take the leftmost 16 octets of that digest and hex-encode them
         (lowercase) to form the 32-character agent-id.

     5.  Combine with the chosen namespace to form the complete AID:
         did:aip:<namespace>:<agent-id>.

     This derivation is deterministic and cryptographically self-
     verifying: possession of the private key corresponding to the
     registered public key is both necessary and sufficient to prove
     control of the AID.

  4.3.  AIP Namespace Catalog

     Standard and community AID namespace registrations are defined by the
     immutable AIP Catalog Snapshot identified in Section 17.15 and
     exposed by conformant Registries through the Namespace Catalog
     endpoint defined there.  The Draft-02 Catalog Snapshot contains the
     standard namespace entries for personal, enterprise, service,
     orchestrator, ephemeral, and registry agents.

     Namespace registration metadata is normative for namespace-level
     lifecycle rules.  If a namespace entry sets requires_task_id: true,
     Principal Tokens for agents in that namespace MUST contain a non-
     empty task_id.  If a namespace entry sets reserved: true, the
     namespace MUST NOT be registered through the normal POST /v1/agents
     flow.

     Namespaces are immutable once registered.  Custom or community
     namespaces MUST be registered in the AIP Namespace Catalog before
     they are treated as interoperable AIP namespaces.

  4.4.  Agent Identity Object Schema

     The Agent Identity Object is the base document for an agent.  It
     includes the AID, public key material, and metadata.  The schema is
     defined in Section 5.2 (see also agent-identity.schema.json in the
     schemas directory).

     Key fields:

     *  aid: The agent's AID (REQUIRED)

     *  name: Human-readable agent name (REQUIRED)



  Singla                  Expires 15 November 2026               [Page 18]


  Internet-Draft                     AIP                          May 2026


     *  type: The namespace component of the AID (REQUIRED, MUST match)

     *  model: AI model information including provider and model_id
        (REQUIRED)

     *  public_key: JWK format Ed25519 public key (REQUIRED)

     *  created_at: ISO 8601 timestamp (REQUIRED)

     *  version: Identity version number for key rotation (REQUIRED,
        minimum 1)

     *  previous_key_signature: EdDSA signature by previous key when
        rotating (REQUIRED if version > 1)

  4.5.  Uniqueness and Immutability

     An AID MUST be unique within the authoritative Registry namespace and
     is cryptographically derived from the agent public key.  Once an
     agent is registered in a Registry, its AID is immutable.  An AID
     cannot be reused or transferred within that Registry.  Two agents
     with identical public keys will derive identical AIDs, so the
     cryptographic relationship is deterministic.  If two different public
     keys derive the same AID, the Registry MUST treat the later
     registration as an AID collision and reject it as a duplicate AID.
     If a registration attempt presents a public key that is already
     associated with a registered, non-revoked AID in that Registry, the
     Registry MUST reject the attempt with aid_already_registered.

  5.  Resource Model and Data Structures

     This section defines the core data structures in AIP: JSON Schema
     representations of agents, principals, capabilities, tokens, and
     registration envelopes.  Non-JWT signed JSON objects use the
     canonical JSON serialization rules of Section 2.1 unless a specific
     object defines a narrower detached-signature target.

  5.1.  Resource Naming

     Agent Identities (AIDs) are W3C Decentralized Identifiers [W3C-DID]
     using the did:aip method.  AID syntax is normatively defined by the
     AID, namespace, and agent-id ABNF productions in Section 4.1.  This
     section does not define a second AID grammar.  JSON Schemas and
     implementations MUST use grammar equivalent to Section 4.1.







  Singla                  Expires 15 November 2026               [Page 19]


  Internet-Draft                     AIP                          May 2026


     The namespace MUST begin with a lowercase alpha character, MUST NOT
     end with a hyphen, and MUST NOT contain consecutive hyphens.
     Implementations MUST reject AIDs containing uppercase hex digits or
     uppercase namespace characters.

     Concrete namespace values are maintained in the AIP Namespace Catalog
     (Section 17.15), not in this prose table.  The namespace grammar from
     Section 4.1 remains the wire-format constraint; catalog membership
     supplies the interoperability and lifecycle metadata for each
     namespace.

     Any namespace marked reserved: true in the AIP Namespace Catalog MUST
     NOT be registered via the standard POST /v1/agents endpoint.  The
     standard registry namespace is reserved and MUST be created
     exclusively via the Registry Genesis procedure.

     Compound typed identifiers use prefixed UUID v4 values:

      +=============+========+==========================================+
      | Object Type | Prefix | Example                                  |
      +=============+========+==========================================+
      | Capability  | cm:    | cm:550e8400-e29b-41d4-a716-446655440000  |
      | Manifest    |        |                                          |
      +-------------+--------+------------------------------------------+
      | Revocation  | rev:   | rev:6ba7b810-9dad-41d1-80b4-00c04fd430c8 |
      | Object      |        |                                          |
      +-------------+--------+------------------------------------------+
      | Endorsement | end:   | end:6ba7b811-9dad-41d1-80b4-00c04fd430c8 |
      | Object      |        |                                          |
      +-------------+--------+------------------------------------------+
      | Grant       | gr:    | gr:550e8401-e29b-41d4-a716-446655440000  |
      | Request     |        |                                          |
      +-------------+--------+------------------------------------------+
      | Approval    | apr:   | apr:550e8402-e29b-41d4-a716-446655440000 |
      | Envelope    |        |                                          |
      +-------------+--------+------------------------------------------+

                       Table 1: Typed Identifier Prefixes

  5.2.  Agent Identity Object

     The Agent Identity Object is the canonical signed JSON document that
     establishes an agent's identity.  The key-continuity signing target
     for key rotation is defined by the previous_key_signature
     requirements below.

     aid  Type: string.  Required: REQUIRED.  Constraints: MUST match




  Singla                  Expires 15 November 2026               [Page 20]


  Internet-Draft                     AIP                          May 2026


        did:aip ABNF; pattern is lowercase namespace plus a 32-character
        lowercase hexadecimal agent-id derived from the leftmost 128 bits
        of the SHA-256 digest of the agent public key.

     name  Type: string.  Required: REQUIRED.  Constraints: minLength: 1,
        maxLength: 64.

     type  Type: string.  Required: REQUIRED.  Constraints: MUST exactly
        match namespace component of aid; pattern is lowercase
        alphanumeric with optional hyphen-separated segments.

     model  Type: object.  Required: REQUIRED.  Constraints: See sub-
        fields below.

     model.provider  Type: string.  Required: REQUIRED.  Constraints:
        minLength: 1, maxLength: 64.

     model.model_id  Type: string.  Required: REQUIRED.  Constraints:
        minLength: 1, maxLength: 128.

     model.attestation_hash  Type: string.  Required: OPTIONAL for Tier 1,
        SHOULD be present for Tier 2, REQUIRED for Tier 3.  Constraints:
        pattern sha256:<64 lowercase hex characters>.

     created_at  Type: string.  Required: REQUIRED.  Constraints: ISO 8601
        UTC; format: date-time; immutable after registration.

     version  Type: integer.  Required: REQUIRED.  Constraints: minimum:
        1; MUST increment by exactly 1 on key rotation.

     public_key  Type: object.  Required: REQUIRED.  Constraints: JWK per
        [RFC7517]; Ed25519 (kty=OKP, crv=Ed25519) per [RFC8037].

     public_key.kty  Type: string.  Required: REQUIRED.  Constraints:
        const: "OKP".

     public_key.crv  Type: string.  Required: REQUIRED.  Constraints:
        const: "Ed25519".

     public_key.x  Type: string.  Required: REQUIRED.  Constraints:
        pattern ^[A-Za-z0-9_-]{43}$ (32 bytes base64url, no padding).

     public_key.kid  Type: string.  Required: REQUIRED.  Constraints: DID
        URL using the agent AID followed by #key-N where N is a positive
        integer.

     previous_key_signature  Type: string.  Required: OPTIONAL




  Singla                  Expires 15 November 2026               [Page 21]


  Internet-Draft                     AIP                          May 2026


        (version=1); REQUIRED (version>=2).  Constraints: base64url EdDSA
        signature computed by the retiring previous private key over the
        new full Agent Identity Object, serialized using the Section 2.1
        canonical JSON procedure with previous_key_signature set to "";
        pattern ^[A-Za-z0-9_-]+$.

     *Normative requirements:*

     *  The aid, type, and created_at fields MUST NOT change after initial
        registration.

     *  The type field MUST exactly match the namespace component of the
        aid field.

     *  The version field MUST start at 1 and MUST increment by exactly 1
        on each key rotation.

     *  The public_key.kid MUST use format <aid>#key-<n> where <n> starts
        at 1.

     *  The model.attestation_hash field is the protocol binding between
        the registered agent identity and a model binary or version
        manifest.  It SHOULD be present for Tier 2 deployments and MUST be
        present for Tier 3 deployments.  A missing hash means the AID is
        not cryptographically pinned to a specific model artifact.

     *  When version is 2 or greater, previous_key_signature MUST be
        present and MUST be a non-empty base64url string.

     *  For key rotation, the previous_key_signature value MUST be
        generated with the retiring previous private key, not the new
        private key.  The signing target is the complete new Agent
        Identity Object after applying the new version and public_key,
        serialized per Section 2.1 with previous_key_signature temporarily
        set to "".  The computed signature then replaces that empty string
        in the stored Agent Identity Object.  A Registry MUST verify this
        signature with the public key from the immediately previous Agent
        Identity Object version before accepting the rotation.

  5.3.  Capability Manifest

     The Capability Manifest is a versioned, signed JSON document that
     declares the specific permissions granted to an agent.  The signature
     field is computed using the Section 2.1 canonical JSON procedure with
     signature set to "".  The signature_kid field identifies the Ed25519
     verification method used for the signature.





  Singla                  Expires 15 November 2026               [Page 22]


  Internet-Draft                     AIP                          May 2026


     +=============+=======+========+===================================+
     |Field        |  Type |Required| Constraints                       |
     +=============+=======+========+===================================+
     |manifest_id  |string |REQUIRED| pattern: cm:<UUIDv4-lowerhex>     |
     +-------------+-------+--------+-----------------------------------+
     |aid          |string |REQUIRED| MUST match did:aip ABNF           |
     +-------------+-------+--------+-----------------------------------+
     |granted_by   |string |REQUIRED| MUST be a valid W3C DID matching  |
     |             |       |        | did:<method>:<method-specific-id> |
     +-------------+-------+--------+-----------------------------------+
     |version      |integer|REQUIRED| minimum: 1; MUST increment on     |
     |             |       |        | every update including            |
     |             |       |        | scope_revoke                      |
     +-------------+-------+--------+-----------------------------------+
     |issued_at    |string |REQUIRED| ISO 8601 UTC; format: date-time   |
     +-------------+-------+--------+-----------------------------------+
     |expires_at   |string |REQUIRED| ISO 8601 UTC; MUST be after       |
     |             |       |        | issued_at                         |
     +-------------+-------+--------+-----------------------------------+
     |capabilities |object |REQUIRED| See Section 5.9 for all sub-      |
     |             |       |        | fields                            |
     +-------------+-------+--------+-----------------------------------+
     |signature_kid|string |REQUIRED| DID URL controlled by granted_by  |
     +-------------+-------+--------+-----------------------------------+
     |signature    |string |REQUIRED| base64url EdDSA signature;        |
     |             |       |        | pattern: ^[A-Za-z0-9_-]+$         |
     +-------------+-------+--------+-----------------------------------+

                     Table 2: Capability Manifest Fields

     A new manifest_id MUST be generated on every update, including
     scope_revoke operations.  Relying Parties MUST verify the manifest
     signature field using the public key identified by signature_kid
     before trusting any capability declared within it.  The DID portion
     of signature_kid MUST be byte-for-byte equal to granted_by.

  5.4.  Credential Token

     An AIP Credential Token is a compact JWT with the following format:

       aip-token = JWT-header "." JWT-payload "." JWT-signature

     The token MUST be a valid JWT as defined by [RFC7519].  Credential
     Tokens conforming to this specification MUST be signed with EdDSA
     using the registered Ed25519 key identified by the JOSE kid.
     Credential Tokens signed with ES256, RS256, symmetric algorithms,
     none, or non-Ed25519 key material MUST be rejected.




  Singla                  Expires 15 November 2026               [Page 23]


  Internet-Draft                     AIP                          May 2026


     *JWT Header fields:*

           +=======+=============+=================================+
           | Field | Requirement | Value / Constraints             |
           +=======+=============+=================================+
           | typ   | MUST        | "AIP+JWT"                       |
           +-------+-------------+---------------------------------+
           | alg   | MUST        | "EdDSA"                         |
           +-------+-------------+---------------------------------+
           | kid   | MUST        | DID URL identifying the signing |
           |       |             | key; MUST match the kid in the  |
           |       |             | signing agent's Agent Identity  |
           +-------+-------------+---------------------------------+

                           Table 3: JWT Header Fields

     *Credential Token Payload fields:*

     aip_version  string, REQUIRED.  AIP protocol compatibility version.
        MUST be "0.3" for tokens conforming to this specification.  See
        Section 20 for version semantics and Section 9.6.6 for validation.

     iss  string, REQUIRED.  MUST match the did:aip ABNF; MUST equal the
        AID identified by the JWT header kid; MUST equal sub; MUST equal
        sub of the last aip_chain element.

     sub  string, REQUIRED.  MUST match the did:aip ABNF; MUST equal iss.
        For an agent-issued Credential Token, this is the acting leaf
        agent's AID.  This specification does not define an on-behalf-of
        subject distinct from the signing agent.

     aud  string or array, REQUIRED.  Single string or array; MUST include
        the Relying Party's identifier.

     iat  integer, REQUIRED.  Unix timestamp; MUST NOT be in the future,
        with a 30-second clock skew tolerance.

     exp  integer, REQUIRED.  Unix timestamp; MUST be strictly greater
        than iat; TTL limits per Section 8.2.

     jti  string, REQUIRED.  UUID v4 canonical lowercase; unique per
        issuer AID across all delegation chains.

     aip_scope  array, REQUIRED. minItems: 1; uniqueItems: true; each item
        matches <dot-separated-scope-name>.

     aip_chain  array, REQUIRED. minItems: 1; maxItems: 11; each element




  Singla                  Expires 15 November 2026               [Page 24]


  Internet-Draft                     AIP                          May 2026


        is a compact-serialised signed Principal Token JWT.  Elements are
        ordered root-to-leaf, and the last element's sub is the acting
        agent AID.  The maximum length corresponds to delegation depths 0
        through 10.

     aip_principal_assertion  string, OPTIONAL for Tier 1 and Tier 2;
        REQUIRED for Tier 3.  A compact-serialised signed JWT issued by an
        enterprise Identity Provider, such as an OIDC ID Token or
        equivalent JWT-formatted assertion.  The assertion MUST contain a
        sub claim identifying the human principal.  When present, the
        Relying Party MUST verify the assertion's signature against the
        IdP's JWKS endpoint before treating the human identity context as
        valid.  The sub claim in aip_principal_assertion MUST match the
        root Principal Token's principal.id value in aip_chain[0].  The
        issuer (iss) of this JWT MUST NOT be the AIP Registry.  See
        Section 9.19 Steps 11a, 11b, and 11c for normative validation.

     aip_originator_aid  string, OPTIONAL; MUST be present when the agent
        is acting in a delegated agent-to-agent (A2A) workflow as
        specified in Section 10.4.  The value is the AID of the
        originating agent that initiated the A2A workflow.  When present,
        it MUST be a valid did:aip AID conforming to the ABNF in
        Section 4.1 and MUST NOT equal the sub claim of this Credential
        Token.

     aip_registry  string, OPTIONAL.  Advisory URI of the AIP Registry; if
        present, Step 6a trust anchoring is REQUIRED.

     aip_engagement_id  string, OPTIONAL.  Pattern: eng:<UUIDv4-lowerhex>;
        present when the token is scoped to an Engagement Object.

  5.4.1.  Step Execution Token

     A Step Execution Token (SET) is a compact JWT issued by a Registry
     after a step actor successfully claims an Approval Envelope step.  It
     is not an agent-issued Credential Token.  Its issuer is the Registry
     ID, and its subject is the actor AID that claimed the step.

     *SET JWT Header fields:*












  Singla                  Expires 15 November 2026               [Page 25]


  Internet-Draft                     AIP                          May 2026


      +=========+=============+=========================================+
      | Field   | Requirement | Value / Constraints                     |
      +=========+=============+=========================================+
      | typ     | MUST        | "AIP-SET+JWT"                           |
      +---------+-------------+-----------------------------------------+
      | alg     | MUST        | "EdDSA"                                 |
      +---------+-------------+-----------------------------------------+
      | kid     | MUST        | HTTPS URI identifying a Registry step-  |
      |         |             | execution verification key listed in    |
      |         |             | the Registry Trust Record version       |
      |         |             | current at issuance time                |
      +---------+-------------+-----------------------------------------+
      | aip_trv | MUST        | Integer Registry Trust Record version   |
      |         |             | whose                                   |
      |         |             | active_verification_keys.step_execution |
      |         |             | contains kid                            |
      +---------+-------------+-----------------------------------------+

                  Table 4: Step Execution Token Header Fields

     The aip_trv header is a protected JOSE header value used only to
     select an already pinned Registry Trust Record.  It is not a trust
     anchor.  Relying Parties MUST NOT accept a Step Execution Token
     unless they already have pinned trust state for iss and for the
     indicated Registry Trust Record version.

     *SET Payload fields:*

     +=====================+=======+===========+=========================+
     |Field                |  Type |  Required | Constraints             |
     +=====================+=======+===========+=========================+
     |aip_version          |string |REQUIRED   | AIP protocol            |
     |                     |       |           | compatibility           |
     |                     |       |           | version; MUST be        |
     |                     |       |           | "0.3" for this spec     |
     +---------------------+-------+-----------+-------------------------+
     |iss                  |string |REQUIRED   | Registry ID HTTPS       |
     |                     |       |           | URI; MUST match the     |
     |                     |       |           | issuing Registry        |
     |                     |       |           | Trust Record            |
     +---------------------+-------+-----------+-------------------------+
     |sub                  |string |REQUIRED   | AID of the claimed      |
     |                     |       |           | step actor; MUST        |
     |                     |       |           | match the referenced    |
     |                     |       |           | Approval Envelope       |
     |                     |       |           | step actor              |
     +---------------------+-------+-----------+-------------------------+
     |aud                  |string/|REQUIRED   | Single string or        |



  Singla                  Expires 15 November 2026               [Page 26]


  Internet-Draft                     AIP                          May 2026


     |                     |array  |           | array; MUST include     |
     |                     |       |           | the Relying Party's     |
     |                     |       |           | identifier              |
     +---------------------+-------+-----------+-------------------------+
     |iat                  |integer|REQUIRED   | Unix timestamp; MUST    |
     |                     |       |           | NOT be in the future    |
     +---------------------+-------+-----------+-------------------------+
     |exp                  |integer|REQUIRED   | Unix timestamp; MUST    |
     |                     |       |           | be strictly greater     |
     |                     |       |           | than iat; MUST NOT      |
     |                     |       |           | exceed the Step         |
     |                     |       |           | Execution Token TTL     |
     |                     |       |           | limit defined below     |
     +---------------------+-------+-----------+-------------------------+
     |jti                  |string |REQUIRED   | UUID v4 canonical       |
     |                     |       |           | lowercase; unique per   |
     |                     |       |           | Registry issuer         |
     |                     |       |           | across all SETs         |
     +---------------------+-------+-----------+-------------------------+
     |aip_scope            |array  |REQUIRED   | Scopes authorised for   |
     |                     |       |           | the claimed step        |
     +---------------------+-------+-----------+-------------------------+
     |aip_chain            |array  |REQUIRED   | Principal Token chain   |
     |                     |       |           | for the actor AID in    |
     |                     |       |           | sub                     |
     +---------------------+-------+-----------+-------------------------+
     |aip_registry         |string |OPTIONAL   | If present, MUST        |
     |                     |       |           | equal iss               |
     +---------------------+-------+-----------+-------------------------+
     |aip_approval_id      |string |REQUIRED   | Approval Envelope       |
     |                     |       |           | identifier; pattern:    |
     |                     |       |           | apr:<UUIDv4-lowerhex>   |
     +---------------------+-------+-----------+-------------------------+
     |aip_step_kind        |string |REQUIRED   | Either forward or       |
     |                     |       |           | compensation            |
     +---------------------+-------+-----------+-------------------------+
     |aip_approval_step    |integer|CONDITIONAL| 1-based step_index;     |
     |                     |       |           | REQUIRED when           |
     |                     |       |           | aip_step_kind is        |
     |                     |       |           | forward; MUST be        |
     |                     |       |           | absent for              |
     |                     |       |           | compensation SETs       |
     +---------------------+-------+-----------+-------------------------+
     |aip_compensation_step|integer|CONDITIONAL| 1-based                 |
     |                     |       |           | compensation_index;     |
     |                     |       |           | REQUIRED when           |
     |                     |       |           | aip_step_kind is        |
     |                     |       |           | compensation; MUST be   |



  Singla                  Expires 15 November 2026               [Page 27]


  Internet-Draft                     AIP                          May 2026


     |                     |       |           | absent for forward      |
     |                     |       |           | SETs                    |
     +---------------------+-------+-----------+-------------------------+
     |aip_engagement_id    |string |OPTIONAL   | Engagement Object       |
     |                     |       |           | identifier when the     |
     |                     |       |           | parent Approval         |
     |                     |       |           | Envelope is             |
     |                     |       |           | engagement-scoped       |
     +---------------------+-------+-----------+-------------------------+

                  Table 5: Step Execution Token Payload Fields

     The Registry MUST derive a Step Execution Token TTL limit as the
     minimum of: (1) the Registry's step_claim_timeout_seconds value
     published in /v1/registry-metadata; (2) the lowest ttl_max_seconds
     value for any requested aip_scope in the synced AIP Scope Catalog;
     and (3) the Tier ceiling for the highest-risk requested scope from
     Section 8.2.  The Registry MUST set exp no later than iat +
     effective_set_ttl_limit.  A Relying Party validating a SET MUST
     compute the same scope and Tier limit through Section 9.7 and reject
     a SET whose exp - iat exceeds that limit with invalid_token.  A
     Registry completing or failing a step MUST also enforce the stored
     claim deadline, even if the SET has not yet expired.

  5.5.  Principal Token

     A Principal Token is a JWT payload encoding one delegation link in
     the AIP principal chain.  Principal Tokens are embedded as compact-
     serialised JWTs in the aip_chain array of a Credential Token or Step
     Execution Token.

     A Principal Token MUST be a compact-serialised JWT signed using
     EdDSA.  Its JOSE header is outside the payload schema but is
     normative: typ MUST be "JWT", alg MUST be "EdDSA", and kid MUST be a
     DID URL identifying an Ed25519 verification method controlled by the
     token issuer identified by iss.  For the root Principal Token
     (delegation_depth 0), the issuer is the root principal.id.  For
     delegated Principal Tokens, the issuer is the parent agent AID in
     delegated_by, and that parent AID MUST be registered in the
     authoritative AIP Registry.  Relying Parties resolve delegated
     Principal Token signing keys through the Registry historical public-
     key endpoint and verify that the returned key was valid at the
     Principal Token's issued_at instant.  Principal Tokens signed with
     ES256, RS256, symmetric algorithms, none, or non-Ed25519 key material
     MUST be rejected.  X25519 verification methods MUST NOT be used for
     Principal Token signing.





  Singla                  Expires 15 November 2026               [Page 28]


  Internet-Draft                     AIP                          May 2026


     +======================+=======+=================+=================+
     | Field                |  Type |     Required    |Constraints      |
     +======================+=======+=================+=================+
     | iss                  |string |REQUIRED         |W3C DID or       |
     |                      |       |                 |did:aip AID; for |
     |                      |       |                 |delegation_depth |
     |                      |       |                 |0: MUST equal    |
     |                      |       |                 |principal.id; for|
     |                      |       |                 |delegation_depth |
     |                      |       |                 |> 0: MUST equal  |
     |                      |       |                 |delegated_by     |
     +----------------------+-------+-----------------+-----------------+
     | sub                  |string |REQUIRED         |MUST match       |
     |                      |       |                 |did:aip ABNF     |
     +----------------------+-------+-----------------+-----------------+
     | principal            |object |REQUIRED         |See sub-fields   |
     |                      |       |                 |below            |
     +----------------------+-------+-----------------+-----------------+
     | principal.type       |string |REQUIRED         |enum: ["human",  |
     |                      |       |                 |"organisation"]  |
     +----------------------+-------+-----------------+-----------------+
     | principal.id         |string |REQUIRED         |W3C DID; MUST NOT|
     |                      |       |                 |use did:aip      |
     |                      |       |                 |method; MUST be  |
     |                      |       |                 |byte-for-byte    |
     |                      |       |                 |identical across |
     |                      |       |                 |all chain        |
     |                      |       |                 |elements         |
     +----------------------+-------+-----------------+-----------------+
     | delegated_by         |string/|REQUIRED         |null when        |
     |                      |null   |                 |delegation_depth |
     |                      |       |                 |is 0; MUST be a  |
     |                      |       |                 |did:aip AID when |
     |                      |       |                 |delegation_depth |
     |                      |       |                 |> 0; MUST NOT    |
     |                      |       |                 |equal sub        |
     +----------------------+-------+-----------------+-----------------+
     | delegation_depth     |integer|REQUIRED         |minimum: 0,      |
     |                      |       |                 |maximum: 10; MUST|
     |                      |       |                 |equal the array  |
     |                      |       |                 |index of this    |
     |                      |       |                 |token in         |
     |                      |       |                 |aip_chain        |
     +----------------------+-------+-----------------+-----------------+
     | max_delegation_depth |integer|OPTIONAL         |minimum: 0,      |
     |                      |       |                 |maximum: 10;     |
     |                      |       |                 |default: 3 when  |
     |                      |       |                 |absent; only the |



  Singla                  Expires 15 November 2026               [Page 29]


  Internet-Draft                     AIP                          May 2026


     |                      |       |                 |value from       |
     |                      |       |                 |aip_chain[0]     |
     |                      |       |                 |governs the chain|
     +----------------------+-------+-----------------+-----------------+
     | issued_at            |string |REQUIRED         |ISO 8601 UTC;    |
     |                      |       |                 |format: date-time|
     +----------------------+-------+-----------------+-----------------+
     | expires_at           |string |REQUIRED         |ISO 8601 UTC;    |
     |                      |       |                 |MUST be strictly |
     |                      |       |                 |after issued_at  |
     +----------------------+-------+-----------------+-----------------+
     | purpose              |string |OPTIONAL         |maxLength: 128;  |
     |                      |       |                 |signed consent/  |
     |                      |       |                 |audit metadata   |
     |                      |       |                 |only; MUST NOT be|
     |                      |       |                 |used as an       |
     |                      |       |                 |authorization    |
     |                      |       |                 |constraint       |
     +----------------------+-------+-----------------+-----------------+
     | task_id              |string/|OPTIONAL;        |minLength: 1,    |
     |                      |null   |REQUIRED when the|maxLength: 256   |
     |                      |       |subject namespace|when non-null;   |
     |                      |       |catalog entry has|enforced at      |
     |                      |       |requires_task_id:|registration and |
     |                      |       |true             |during Step 8    |
     |                      |       |                 |chain validation |
     +----------------------+-------+-----------------+-----------------+
     | scope                |array  |REQUIRED         |minItems: 1;     |
     |                      |       |                 |uniqueItems: true|
     +----------------------+-------+-----------------+-----------------+
     | acr                  |string |OPTIONAL;        |Authentication   |
     |                      |       |REQUIRED when    |context class    |
     |                      |       |grant ceremony is|reference        |
     |                      |       |G3               |                 |
     +----------------------+-------+-----------------+-----------------+
     | amr                  |array  |OPTIONAL;        |Authentication   |
     |                      |       |REQUIRED when    |method reference |
     |                      |       |grant ceremony is|values per       |
     |                      |       |G3               |[RFC8176]        |
     +----------------------+-------+-----------------+-----------------+

                       Table 6: Principal Token Fields

     The principal.id field MUST be byte-for-byte identical across every
     Principal Token in the same aip_chain array.  The principal.id MUST
     NOT begin with did:aip:.





  Singla                  Expires 15 November 2026               [Page 30]


  Internet-Draft                     AIP                          May 2026


     For a root Principal Token produced by AIP-GRANT, issued_at is the
     issuer's current UTC signing time and expires_at equals issued_at
     plus the GrantResponse approved_delegation_valid_for_seconds value.
     The detailed derivation rule is defined in Section 12.3.

     The purpose field, when present, is a signed human-readable consent
     and audit claim.  It is not a machine-enforced authorization
     constraint.  Relying Parties MAY display or log purpose for operator
     context, but MUST NOT use it to grant capabilities, satisfy scope
     checks, or override Capability Manifest, Capability Overlay, Approval
     Envelope, or policy evaluation.

  5.6.  Registration Envelope

     The Registration Envelope is the request body submitted to POST /v1/
     agents to register a new AIP agent.



































  Singla                  Expires 15 November 2026               [Page 31]


  Internet-Draft                     AIP                          May 2026


     +===================+======+========+===============================+
     |Field              | Type |Required| Constraints                   |
     +===================+======+========+===============================+
     |identity           |object|REQUIRED| MUST conform to agent-        |
     |                   |      |        | identity schema; version      |
     |                   |      |        | MUST be 1;                    |
     |                   |      |        | previous_key_signature MUST   |
     |                   |      |        | NOT be present                |
     +-------------------+------+--------+-------------------------------+
     |capability_manifest|object|REQUIRED| MUST conform to capability-   |
     |                   |      |        | manifest schema; version      |
     |                   |      |        | MUST be 1; aid MUST equal     |
     |                   |      |        | identity.aid                  |
     +-------------------+------+--------+-------------------------------+
     |principal_token    |string|REQUIRED| Compact JWT                   |
     |                   |      |        | (header.payload.signature);   |
     |                   |      |        | for direct registration       |
     |                   |      |        | delegation_depth MUST be 0    |
     |                   |      |        | and delegated_by MUST be      |
     |                   |      |        | null; for sub-agent           |
     |                   |      |        | registration                  |
     |                   |      |        | delegation_depth MUST be      |
     |                   |      |        | greater than 0 and            |
     |                   |      |        | delegated_by MUST identify    |
     |                   |      |        | the registered parent AID     |
     +-------------------+------+--------+-------------------------------+
     |grant_tier         |string|REQUIRED| enum: ["G1", "G2", "G3"];     |
     |                   |      |        | MUST meet the minimum Grant   |
     |                   |      |        | Tier required by the          |
     |                   |      |        | highest synced AIP Scope      |
     |                   |      |        | Catalog tier in               |
     |                   |      |        | capability_manifest           |
     +-------------------+------+--------+-------------------------------+

                     Table 7: Registration Envelope Fields

     A Registration Envelope registers exactly one agent: the AID in
     identity.aid.  The submitted principal_token payload sub MUST equal
     that AID.  Direct principal-to-agent registrations use a root
     Principal Token with delegation_depth: 0 and delegated_by: null.
     Sub-agent registrations use a delegated Principal Token signed by the
     registered parent agent identified in delegated_by; the Registry
     reconstructs the complete principal chain from the parent's stored
     registration chain and the submitted token during Registration Check
     9.






  Singla                  Expires 15 November 2026               [Page 32]


  Internet-Draft                     AIP                          May 2026


  5.7.  Revocation Object

     Revocation is performed by submitting a signed Revocation Object to
     POST /v1/revocations.  The signature field is computed using the
     Section 2.1 canonical JSON procedure with signature set to "".  The
     signing input order is revocation_id, target_id, type, issued_by,
     kid, reason, timestamp, propagate_to_children, scopes_revoked, and
     signature.

      +=====================+=======+=============+=====================+
      |Field                |  Type |   Required  |Constraints          |
      +=====================+=======+=============+=====================+
      |revocation_id        |string |REQUIRED     |pattern:             |
      |                     |       |             |rev:<UUIDv4-lowerhex>|
      +---------------------+-------+-------------+---------------------+
      |target_id            |string |REQUIRED     |MUST be a did:aip AID|
      |                     |       |             |(for full_revoke,    |
      |                     |       |             |scope_revoke,        |
      |                     |       |             |delegation_revoke) or|
      |                     |       |             |a Principal DID (for |
      |                     |       |             |principal_revoke)    |
      +---------------------+-------+-------------+---------------------+
      |type                 |string |REQUIRED     |enum: ["full_revoke",|
      |                     |       |             |"scope_revoke",      |
      |                     |       |             |"delegation_revoke", |
      |                     |       |             |"principal_revoke"]  |
      +---------------------+-------+-------------+---------------------+
      |issued_by            |string |REQUIRED     |Issuer DID authorised|
      |                     |       |             |for the target, or   |
      |                     |       |             |Registry ID for      |
      |                     |       |             |Registry-generated   |
      |                     |       |             |revocations          |
      +---------------------+-------+-------------+---------------------+
      |kid                  |string |REQUIRED     |Verification key     |
      |                     |       |             |identifier; DID URL  |
      |                     |       |             |controlled by        |
      |                     |       |             |issued_by for        |
      |                     |       |             |external submissions,|
      |                     |       |             |or active Registry   |
      |                     |       |             |CRL key for Registry-|
      |                     |       |             |generated revocations|
      +---------------------+-------+-------------+---------------------+
      |reason               |string |REQUIRED     |enum defined in the  |
      |                     |       |             |Revocation Reason    |
      |                     |       |             |Codes table          |
      +---------------------+-------+-------------+---------------------+
      |timestamp            |string |REQUIRED     |ISO 8601 UTC         |
      +---------------------+-------+-------------+---------------------+



  Singla                  Expires 15 November 2026               [Page 33]


  Internet-Draft                     AIP                          May 2026


      |propagate_to_children|boolean|OPTIONAL     |default: false       |
      +---------------------+-------+-------------+---------------------+
      |scopes_revoked       |array  |REQUIRED when|minItems: 1          |
      |                     |       |scope_revoke;|                     |
      |                     |       |MUST NOT     |                     |
      |                     |       |otherwise    |                     |
      +---------------------+-------+-------------+---------------------+
      |signature            |string |REQUIRED     |base64url EdDSA      |
      +---------------------+-------+-------------+---------------------+

                       Table 8: Revocation Object Fields

     *Revocation Types:*

     *  *full_revoke* - Permanently revokes the AID.

     *  *scope_revoke* - Invalidates specific scopes for the agent.  For
        Tier 1 and 2, this MUST cause Relying Parties to reject Credential
        Tokens containing the revoked scopes (Step 7, Section 9).

     *  *delegation_revoke* - Invalidates delegation chains rooted at the
        target.  Child agents lose authority; the target AID remains valid
        for direct principal interactions.

     *  *principal_revoke* - Issued by the root principal to revoke their
        authorisation of a target agent (via AID) or all agents under
        their authority (via Principal DID).  Existing Credential Tokens
        and Step Execution Tokens depending on that authorisation become
        invalid immediately.  This validity effect is independent of
        propagate_to_children; that flag controls only whether descendant
        Revocation Objects are materialised.

     *Revocation Reason Codes:* The reason field MUST be one of the
     following values:

















  Singla                  Expires 15 November 2026               [Page 34]


  Internet-Draft                     AIP                          May 2026


     +====================+==============================================+
     | Reason             | Semantics                                    |
     +====================+==============================================+
     | device_compromised | The principal's device or agent host         |
     |                    | holding relevant key material was            |
     |                    | compromised.                                 |
     +--------------------+----------------------------------------------+
     | key_compromised    | The agent private key or signing key was     |
     |                    | directly compromised.                        |
     +--------------------+----------------------------------------------+
     | task_complete      | The agent completed its assigned task        |
     |                    | and no longer requires the delegated         |
     |                    | authority.                                   |
     +--------------------+----------------------------------------------+
     | policy_violation   | The agent or deployment violated             |
     |                    | Registry, principal, or relying-party        |
     |                    | policy.                                      |
     +--------------------+----------------------------------------------+
     | principal_request  | The principal requested revocation           |
     |                    | without a more specific protocol reason.     |
     +--------------------+----------------------------------------------+
     | account_closure    | The principal or deployer account            |
     |                    | associated with the delegation is being      |
     |                    | closed.                                      |
     +--------------------+----------------------------------------------+
     | heartbeat_timeout  | Registry-generated reason for Dead Man's     |
     |                    | Switch expiry.                               |
     +--------------------+----------------------------------------------+
     | lifecycle_expired  | Registry-generated reason for namespace      |
     |                    | lifecycle expiry.                            |
     +--------------------+----------------------------------------------+
     | parent_revoked     | Registry-generated reason for recursive      |
     |                    | child revocation after a parent              |
     |                    | revocation.                                  |
     +--------------------+----------------------------------------------+
     | other              | Other auditable reason.  Implementations     |
     |                    | SHOULD record additional detail in local     |
     |                    | audit metadata.                              |
     +--------------------+----------------------------------------------+

                        Table 9: Revocation Reason Codes

     Externally submitted Revocation Objects MUST NOT use parent_revoked,
     heartbeat_timeout, or lifecycle_expired; those values are reserved
     for Registry-generated Revocation Objects.






  Singla                  Expires 15 November 2026               [Page 35]


  Internet-Draft                     AIP                          May 2026


  5.8.  Endorsement Object

     Any Relying Party or agent MAY submit a signed Endorsement Object to
     the Registry after a completed interaction.  The signature field is
     computed using the Section 2.1 canonical JSON procedure with
     signature set to "".

     endorsement_id  string, REQUIRED.  Pattern: end:<UUIDv4-lowerhex>.

     from_aid  string, REQUIRED.  MUST NOT equal to_aid.

     to_aid  string, REQUIRED.  MUST NOT equal from_aid.

     task_id  string, REQUIRED. minLength: 1; maxLength: 256.

     outcome  string, REQUIRED.  One of success, partial, or failure.

     score  number, REQUIRED.  Endorsement score in the range 1 through 5
        inclusive.  Values outside this range MUST be rejected with
        endorsement_invalid.

     notes  string or null, OPTIONAL.  Maximum length 512.  Signed audit
        context only; MUST NOT affect reputation scoring or validation.

     timestamp  string, REQUIRED.  ISO 8601 UTC timestamp.

     signature_kid  string, REQUIRED.  DID URL identifying an Ed25519
        verification method controlled by from_aid.

     signature  string, REQUIRED.  Base64url EdDSA signature by from_aid.

     The Registry MUST verify every submitted Endorsement Object
     signature.  The DID portion of signature_kid MUST equal from_aid.
     Only success and partial outcomes increment endorsement_count.
     failure increments incident_count.

     The notes field, when present, is signed human-readable audit context
     about the observed task outcome.  The Registry MUST preserve it as
     part of the Endorsement Object, but MUST NOT parse, classify, or use
     notes to compute reputation scores, increment counters, validate
     capability authorization, or alter endorsement acceptance.
     Reputation effects are determined by the structured fields defined in
     this section and Section 14.








  Singla                  Expires 15 November 2026               [Page 36]


  Internet-Draft                     AIP                          May 2026


  5.9.  Field Constraints and Catalog-Bound Scope Identifiers

     The Capability Manifest capabilities object is a closed object: top-
     level capability families not listed below MUST NOT appear unless a
     Registry accepts them through an explicit private extension policy.
     The immutable machine-readable schema for this draft is
     https://provai.dev/schemas/aip/capability-manifest/draft-02, also
     listed as capability-manifest.schema.json in the JSON Schema Index.

     email  Permitted sub-fields are boolean read, write, send, and
        delete, plus optional integer max_recipients_per_send in the range
        1-100.  Boolean fields default to false when absent.  The
        recipient cap applies only when send is true.

     calendar  Permitted sub-fields are boolean read, write, and delete.
        Boolean fields default to false when absent.

     filesystem  Permitted sub-fields are read and write arrays of
        absolute path strings, plus boolean execute and delete.  Each path
        string MUST be non-empty and no longer than 512 characters.  Empty
        or absent path arrays mean deny-all for that operation.  File
        deletion is permitted only for paths also permitted by write.

     web  Permitted sub-fields are boolean browse, forms_submit, and
        download, plus optional integer max_requests_per_hour in the range
        1-10000.  Boolean fields default to false when absent.

     transactions  The enabled boolean is REQUIRED when the transactions
        object is present.  When enabled is true, max_single_transaction,
        max_daily_total, and currency are REQUIRED; transaction limits
        MUST be greater than zero; currency MUST be an ISO 4217 three-
        letter uppercase currency code.  Optional
        require_confirmation_above MUST be less than or equal to
        max_single_transaction when both are present.

     communicate  The enabled boolean is REQUIRED when the communicate
        object is present.  Permitted channel fields are boolean whatsapp,
        telegram, sms, and voice.  When enabled is true, at least one
        channel field MUST be explicitly set to true; when enabled is
        false, channel fields have no granting effect.

     spawn_agents  The enabled boolean is REQUIRED when the spawn_agents
        object is present.  When enabled is true, integer max_concurrent
        in the range 1-100 is REQUIRED.  Optional types_allowed lists
        namespace labels the agent may spawn; each value MUST be an
        active, spawnable entry in the synced AIP Namespace Catalog unless
        a private namespace policy explicitly permits it.




  Singla                  Expires 15 November 2026               [Page 37]


  Internet-Draft                     AIP                          May 2026


     registry  Permitted sub-fields are Registry control-plane grants.
        Draft-02 defines boolean heartbeat, which grants the
        registry.heartbeat scope for authenticated liveness submissions.

     approvals  Permitted sub-fields are Approval Envelope control-plane
        grants.  Draft-02 defines boolean create, which grants the
        approvals.create scope for submitting Approval Envelopes to POST
        /v1/approvals.

     An absent top-level capability family grants no capability in that
     family.  An empty capabilities object grants no capabilities.
     Implementations MUST NOT treat absent fields as allow-all.

     *Scope Identifier Grammar and Catalog Binding:*

     Scope identifiers are dot-separated lowercase ASCII strings.  Each
     segment MUST begin with a-z or _, and subsequent characters in the
     same segment MAY be a-z, 0-9, or _. The normative pattern is <dot-
     separated-scope-name>.  This permits versioned or tiered scope names
     such as transactions.v2 or filesystem.read.tier1 while preserving a
     non-numeric first character in every segment.

     Concrete scope identifiers and their security metadata are defined by
     the immutable AIP Catalog Snapshot identified in Section 17.15 and
     exposed by conformant Registries through the Scope Map endpoint
     defined in Section 17.15.  A scope is interoperable only when it is
     present with status: "active" or status: "experimental" in the synced
     AIP Scope Catalog, or when a Registry explicitly documents a private
     local extension policy.

     Tokens containing a scope that is absent from the synced AIP Scope
     Catalog, marked reserved, marked removed, or outside an explicitly
     documented local extension policy MUST be rejected with
     invalid_scope.

     Where this document references transactions.* or communicate.*, the
     wildcard is category notation rather than a literal scope string.
     The matching semantics for scope-family entries are defined by the
     AIP Scope Catalog.  In the Draft-02 catalog, transactions.* includes
     the bare transactions scope, any active scope beginning with
     transactions., and capabilities.transactions.enabled: true in the
     Capability Manifest; communicate.* includes active scopes beginning
     with communicate. and capabilities.communicate.enabled: true in the
     Capability Manifest.







  Singla                  Expires 15 November 2026               [Page 38]


  Internet-Draft                     AIP                          May 2026


     Empty arrays [] for filesystem.read or filesystem.write MUST be
     interpreted as deny-all.  A require_confirmation_above value above
     max_single_transaction is vacuous and MUST be rejected.  When
     communicate.enabled is true, at least one channel MUST be explicitly
     set to true.

  5.10.  Delegation Rules

     *Rule D-1.* A delegated agent MUST NOT grant scopes or looser
     constraint values than its own Capability Manifest contains.

     *Rule D-2.* A delegated agent MUST NOT issue a Principal Token with
     max_delegation_depth greater than its remaining depth
     (max_delegation_depth - delegation_depth).

     *Rule D-3.* Implementations MUST reject any Credential Token where
     the delegation_depth of any chain token exceeds the root token's
     max_delegation_depth.  The hard protocol maximum for
     max_delegation_depth is 10.

     *Rule D-4.* The root Principal Token (index 0) MUST have
     delegation_depth = 0.  Each subsequent token at index i MUST have
     delegation_depth = i.  No gaps, skips, or repeated values are
     permitted.  Because depths 0 through 10 are the complete allowed
     range, a valid aip_chain contains at most 11 elements.

     *Rule D-5.* Each delegation chain token MUST be signed by the private
     key of the delegated_by AID (or root principal for depth 0).  For
     non-root delegation tokens, the signing AID MUST be a registered AIP
     agent whose public key can be resolved from the Registry as specified
     by Credential Token validation Step 8d-2.

  5.11.  Capability Overlays

     A Capability Overlay is a signed restriction document stored in the
     Registry.  It narrows an agent's effective capability set for
     operations within a specific engagement or issuer context.

     *Rule CO-1 (Attenuation Only):* An overlay MUST NOT expand any
     constraint value beyond what the base Capability Manifest permits.
     The effective capability set is always the intersection of the base
     manifest and all active overlays scoped to the engagement or issuer.









  Singla                  Expires 15 November 2026               [Page 39]


  Internet-Draft                     AIP                          May 2026


      +===============+=========+==========+============================+
      | Field         |   Type  | Required | Constraints                |
      +===============+=========+==========+============================+
      | overlay_id    | string  | REQUIRED | Pattern:                   |
      |               |         |          | co:<UUIDv4-lowerhex>       |
      +---------------+---------+----------+----------------------------+
      | aid           | string  | REQUIRED | The target agent's AID     |
      +---------------+---------+----------+----------------------------+
      | engagement_id | string  | OPTIONAL | Pattern:                   |
      |               |         |          | eng:<UUIDv4-lowerhex>;     |
      |               |         |          | links to Engagement Object |
      +---------------+---------+----------+----------------------------+
      | issued_by     | string  | REQUIRED | DID of the overlay issuer; |
      |               |         |          | MUST be did:web or did:aip |
      |               |         |          | (MUST NOT be did:key)      |
      +---------------+---------+----------+----------------------------+
      | overlay_type  | string  | REQUIRED | MUST be "restrict"         |
      +---------------+---------+----------+----------------------------+
      | issued_at     | string  | REQUIRED | ISO 8601 UTC timestamp     |
      +---------------+---------+----------+----------------------------+
      | expires_at    | string  | REQUIRED | ISO 8601 UTC; MUST be      |
      |               |         |          | strictly after issued_at   |
      +---------------+---------+----------+----------------------------+
      | version       | integer | REQUIRED | Positive integer;          |
      |               |         |          | monotonically increasing   |
      |               |         |          | per (aid, engagement_id,   |
      |               |         |          | issued_by) tuple           |
      +---------------+---------+----------+----------------------------+
      | constraints   | object  | REQUIRED | Uses the same schema as    |
      |               |         |          | Capability Manifest        |
      |               |         |          | capabilities sub-object    |
      +---------------+---------+----------+----------------------------+
      | signature_kid | string  | REQUIRED | DID URL controlled by      |
      |               |         |          | issued_by                  |
      +---------------+---------+----------+----------------------------+
      | signature     | string  | REQUIRED | Base64url EdDSA signature  |
      |               |         |          | by issued_by over the      |
      |               |         |          | Section 2.1 signing input  |
      +---------------+---------+----------+----------------------------+

                      Table 10: Capability Overlay Fields

     *Overlay Rules:*








  Singla                  Expires 15 November 2026               [Page 40]


  Internet-Draft                     AIP                          May 2026


     1.  *CO-1 (Attenuation Only):* For every field in constraints, the
         value MUST be equal to or more restrictive than the corresponding
         value in the base Capability Manifest.  Constraint comparison is
         recursive for nested objects.  An omitted overlay field inherits
         the effective base value and MUST NOT be interpreted as removing
         or relaxing the base constraint.

     2.  *CO-2 (Issuer DID Method):* The issued_by DID MUST use did:web or
         did:aip.  Overlays signed by did:key MUST be rejected with
         overlay_issuer_invalid.  The DID portion of signature_kid MUST be
         byte-for-byte equal to issued_by.

     3.  *CO-3 (Version Monotonicity):* A new overlay for the same (aid,
         engagement_id, issued_by) tuple MUST have a strictly higher
         version than the current active overlay.  A submission whose
         version is less than or equal to the current active overlay
         version MUST be rejected with overlay_version_conflict.

     4.  *CO-4 (Expiry Handling):* Expired overlays MUST be treated as
         absent.

     5.  *CO-5 (Engagement Termination):* If an Engagement Object
         associated with an overlay's engagement_id is terminated, all
         overlays for that engagement MUST be invalidated atomically by
         the Registry.

     6.  *CO-6 (Multiple Overlays):* When multiple overlays apply to the
         same agent, the effective capability set is the intersection of
         ALL applicable overlays with the base manifest.

     *Effective Capability Computation:*

       effective = base_manifest.capabilities
       for each active_overlay in applicable_overlays:
           effective = intersect(effective, active_overlay.constraints)

     Where intersect applies per-field, the following type-specific rules
     are normative.  Scope set to false removes that scope through the
     boolean rule below.

     The intersect operation is defined recursively over JSON values:

     Objects  For each object member present in the base value, if the
        overlay omits that member, the effective value is the base member
        unchanged.  If the overlay supplies that member, apply intersect
        recursively.  If the overlay supplies a member that is absent from
        the base value, the overlay is valid only when this specification
        or the synced AIP Scope Catalog defines absence of that member as



  Singla                  Expires 15 November 2026               [Page 41]


  Internet-Draft                     AIP                          May 2026


        an unrestricted allowance or default value that the overlay
        narrows.  Otherwise, the overlay expands the manifest and MUST be
        rejected with overlay_exceeds_manifest.

     Booleans  Boolean fields use logical AND. false is more restrictive
        than true.

     Numbers  Numeric fields that represent maximum allowances, rate
        limits, budget caps, concurrency caps, or confirmation thresholds
        use min(base, overlay).  In the Draft-02 standard Capability
        Manifest schema, this rule applies to
        email.max_recipients_per_send, web.max_requests_per_hour,
        transactions.max_single_transaction, transactions.max_daily_total,
        transactions.require_confirmation_above, and
        spawn_agents.max_concurrent.  A lower require_confirmation_above
        value is more restrictive because it requires explicit
        confirmation for a larger set of transactions.  If the base
        manifest omits an optional numeric cap whose absence is defined as
        "no cap" or "no confirmation threshold", an overlay MAY add that
        cap and the effective value is the overlay value.  Numeric fields
        whose ordering semantics are not defined by the synced AIP Scope
        Catalog or this specification MUST NOT be narrowed by ordering;
        the overlay value MUST equal the base value or be rejected with
        overlay_exceeds_manifest.

     Arrays  Arrays of allowed values, including filesystem path arrays
        and spawn_agents.types_allowed, use set intersection.  The result
        MAY be an empty array, which means deny-all for that allowed-value
        list.  If the base manifest omits an optional allowed-value array
        whose absence is defined as all catalog-valid values being
        allowed, an overlay MAY add the array and the effective value is
        the overlay array.

     Strings and enums  String and enum fields are not ordered.  If an
        overlay supplies a string or enum value, it MUST be byte-for-byte
        equal to the base value unless the synced AIP Scope Catalog
        defines explicit subset semantics for that field.  Otherwise the
        overlay MUST be rejected with overlay_exceeds_manifest.  For
        example, transactions.currency set to "GBP" cannot attenuate a
        base transactions.currency value of "USD".  If the overlay omits
        transactions.currency, the base currency is inherited unchanged.

     Null and unknown types  null and any value type not covered above
        MUST NOT be used to relax or erase a base constraint.  A non-equal
        overlay value of an unknown type MUST be rejected with
        overlay_exceeds_manifest.





  Singla                  Expires 15 November 2026               [Page 42]


  Internet-Draft                     AIP                          May 2026


  5.12.  Engagement Objects

     An Engagement Object is a mutable Registry resource that models a
     multi-party engagement.  It is the parent container for Capability
     Overlays scoped via engagement_id, Approval Envelopes scoped via
     engagement_id, and participant roster and approval gate state.

     *Engagement Object Fields:*

     engagement_id (string; REQUIRED)
        Pattern: eng:<UUIDv4-lowerhex>

     title (string; REQUIRED)
        maxLength: 256

     hiring_operator (string; REQUIRED)
        DID; MUST be did:web or did:aip

     deploying_principal (string; REQUIRED)
        DID of the deploying principal

     created_at (string; REQUIRED)
        ISO 8601 UTC

     expires_at (string; REQUIRED)
        ISO 8601 UTC; MUST be after created_at

     status (string; REQUIRED)
        One of: "proposed", "active", "suspended", "completed",
        "terminated"

     participants (array; REQUIRED)
        Array of Participant objects

     approval_gates (array; OPTIONAL)
        Array of Approval Gate objects

     change_log (array; REQUIRED)
        Append-only array of Change Log Entry objects

     hiring_operator_signature (string; REQUIRED)
        Base64url EdDSA signature by hiring_operator over the top-level
        engagement signing input defined below

     hiring_operator_kid (string; REQUIRED)
        DID URL identifying the Ed25519 verification method for
        hiring_operator_signature




  Singla                  Expires 15 November 2026               [Page 43]


  Internet-Draft                     AIP                          May 2026


     deploying_principal_signature (string; COND.)
        Base64url EdDSA countersignature by deploying_principal over the
        same top-level engagement signing input defined below; REQUIRED
        for active, suspended, completed, and terminated Engagement
        Objects

     deploying_principal_kid (string; COND.)
        DID URL identifying the Ed25519 verification method for
        deploying_principal_signature; REQUIRED whenever
        deploying_principal_signature is present

     version (integer; REQUIRED)
        Positive integer; MUST equal max(change_log.seq)

     *Participant object fields:* aid (REQUIRED), role (REQUIRED,
     maxLength: 64), capability_overlay_id (OPTIONAL), added_at (REQUIRED,
     ISO 8601), added_by (REQUIRED, DID), removed_at (OPTIONAL, ISO 8601).

     *Approval Gate object fields:* gate_id (REQUIRED, pattern:
     gate:<lowercase-token>), name (REQUIRED, maxLength: 128),
     required_approver (REQUIRED, DID), trigger (REQUIRED, scope:<scope-
     string> or action_type:<action-type>), status (REQUIRED, one of:
     "pending", "approved", "rejected"), approved_at (OPTIONAL, ISO 8601).

     *Top-level engagement signature input:* Both
     hiring_operator_signature and, when present,
     deploying_principal_signature MUST be computed over the same JCS-
     canonical JSON serialization of the immutable engagement agreement
     object containing only engagement_id, title, hiring_operator,
     deploying_principal, created_at, and expires_at.  The top-level
     signing input MUST NOT include mutable lifecycle or roster state
     (status, participants, approval_gates, change_log, or version) and
     MUST NOT include top-level signature or *_kid fields.  Mutable state
     is authenticated by the signed append-only change_log entries.  The
     countersignature does not sign the other party's signature value.

     *Change Log Entry fields:* seq (REQUIRED, monotonically increasing
     from 1), timestamp (REQUIRED, ISO 8601), action (REQUIRED), actor
     (REQUIRED, DID), actor_kid (REQUIRED DID URL), payload (OPTIONAL,
     object), signature (REQUIRED, Base64url EdDSA by actor over the
     Section 2.1 signing input with the entry signature excluded).

     *Engagement signature verification profile:* Each top-level signature
     and each change-log entry signature MUST identify its verification
     key with the corresponding *_kid field.  The kid value MUST be a DID
     URL whose DID portion is byte-for-byte equal to the signer DID:
     hiring_operator for hiring_operator_signature, deploying_principal
     for deploying_principal_signature, and the change-log entry actor for



  Singla                  Expires 15 November 2026               [Page 44]


  Internet-Draft                     AIP                          May 2026


     an entry signature.  For did:aip signer DIDs, the Registry MUST
     resolve the verification method through its registered public-key
     endpoint for that AID.  For other DID methods, the Registry MUST use
     the signer's DID method resolution rules.  The resolved verification
     method MUST be Ed25519 verification material controlled by the signer
     DID.  Missing kid fields, malformed DID URLs, signer/key DID
     mismatches, unsupported key types, failed DID resolution, or failed
     EdDSA signature verification MUST cause rejection with
     engagement_signature_invalid.

     Defined change log actions: engagement_created,
     engagement_countersigned, participant_added, participant_removed,
     participant_role_changed, gate_added, gate_approved, gate_rejected,
     engagement_suspended, engagement_resumed, engagement_completed,
     engagement_terminated.

     The Registry MUST reject any request that modifies or deletes an
     existing change log entry.  Only appends are permitted.

     *Engagement version semantics:* The version field is the current
     change-log sequence number, not an independent counter.  On creation,
     the Registry MUST create exactly one engagement_created entry with
     seq: 1 and set version: 1.  Each accepted mutation after creation
     MUST append exactly one new change-log entry whose seq is previous
     version + 1, and the Registry MUST set version to that new seq in the
     same atomic update.  Therefore, for every stored Engagement Object,
     version MUST equal max(change_log[*].seq).  A mutation that changes
     status, participants, approval gates, countersignature state, or
     termination state without appending a matching change-log entry MUST
     be rejected.

     *Engagement Lifecycle:*

       proposed --> active --> completed
                      |
                      +--> suspended --> active (resumed)
                      |
                      +--> terminated

     *Engagement Lifecycle Transitions:*

     *  proposed to active: Requires both hiring_operator_signature and
        deploying_principal_signature.  Missing
        deploying_principal_signature during activation MUST be rejected
        with engagement_countersign_required.

     *  active to suspended / completed: Hiring operator only.




  Singla                  Expires 15 November 2026               [Page 45]


  Internet-Draft                     AIP                          May 2026


     *  active/suspended to terminated: Either party.

     *Termination Cascade:* When an Engagement is terminated:

     1.  The Registry MUST set status: "terminated" atomically.

     2.  All Capability Overlays linked to this engagement_id MUST be
         invalidated (per Rule CO-5).

     3.  All Approval Envelopes in pending_approval, approved, or
         executing status scoped to this engagement_id MUST be
         transitioned to cancelled using the Approval Envelope
         cancellation rules in Section 13.6.

     4.  Subsequent Credential Token validation for operations scoped to
         this engagement MUST fail with engagement_terminated.

     This termination cascade applies only when an Engagement transitions
     to terminated.  Transition to completed does not trigger any
     Capability Overlay invalidation or Approval Envelope cancellation
     cascade.

  6.  Registration Protocol

  6.1.  Envelope Submission

     The Registration Envelope request body is defined only in
     Section 5.6.  An agent is registered by submitting that object to
     POST /v1/agents.  This section defines Registry processing and
     validation; it does not define a second Registration Envelope schema.

  6.2.  Registration Validation

     The Registry MUST perform the following checks in order before
     accepting a Registration Envelope.  The Registry MUST either accept
     all or reject all — partial registration MUST NOT be possible.

     If any required condition in Checks 1 through 15, including their
     lettered subchecks, fails and that check does not explicitly name a
     more specific error code, the Registry MUST reject the Registration
     Envelope with registration_invalid.  Because the checks are ordered,
     the Registry SHOULD report the error code associated with the first
     failed check.

     1.   Check 1. identity MUST be present and MUST be valid JSON
          conforming to the Agent Identity schema.





  Singla                  Expires 15 November 2026               [Page 46]


  Internet-Draft                     AIP                          May 2026


     2.   Check 2. identity.aid MUST match the did:aip ABNF grammar
          defined in Section 4.1.

     3.   Check 3. identity.type MUST equal the namespace component of
          identity.aid.  The namespace MUST have an active, non-reserved
          entry in the Registry's synced AIP Namespace Catalog, unless the
          Registry explicitly documents a private local namespace policy.
          A mismatch, unknown namespace, removed namespace, or reserved
          namespace MUST be rejected with registration_invalid.

     4.   Check 4. identity.aid MUST NOT already exist in the Registry,
          and identity.public_key MUST NOT already be associated with a
          registered, non-revoked AID in the Registry.  If either
          condition fails, the Registry MUST reject with
          aid_already_registered.

     5.   Check 5. identity.public_key MUST be an Ed25519 JWK with
          kty="OKP", crv="Ed25519", and a 43-character base64url x value.

     6.   Check 6. capability_manifest MUST be present and MUST be valid
          JSON conforming to the Capability Manifest schema.  It MUST
          include manifest_id, aid, granted_by, version, issued_at,
          expires_at, capabilities, and signature.  The version field MUST
          equal 1 for initial registration; manifest_id MUST match the cm:
          UUID pattern; issued_at and expires_at MUST be valid date-time
          values; capabilities MUST be an object; and signature MUST be a
          non-empty base64url value.  The capability_manifest.expires_at
          value MUST be in the future at the time of registration.

     7.   Check 7. capability_manifest.aid MUST equal identity.aid.

     8.   Check 8.  The principal_token string MUST be decodable as a
          compact-serialised JWT, MUST conform to the Principal Token
          schema, and MUST carry a JOSE header with typ equal to "JWT",
          alg equal to "EdDSA", and kid identifying an Ed25519
          verification method controlled by the decoded iss DID or AID.
          For a did:aip issuer, the Registry MUST resolve the key through
          its public-key endpoint for that registered AID.  The Registry
          MUST verify the Principal Token signature using the resolved
          verification method.  If any Check 8 condition fails, the
          Registry MUST reject with registration_invalid.

     9.   Check 9.  The decoded principal_token payload sub MUST equal
          identity.aid.  If delegation_depth is 0, delegated_by MUST be
          null and iss MUST equal principal.id.  If delegation_depth is
          greater than 0, delegated_by MUST be a registered, non-revoked
          parent AID, iss MUST equal delegated_by, and the Registry MUST
          reconstruct the complete candidate chain by appending the



  Singla                  Expires 15 November 2026               [Page 47]


  Internet-Draft                     AIP                          May 2026


          submitted Principal Token to the parent's stored registration
          chain.  The reconstructed chain MUST satisfy the delegation-
          chain rules in Section 9.11, including linkage, consistent root
          principal, scope inheritance, task binding, and maximum
          delegation depth.  The submitted capability_manifest scopes MUST
          be a subset of both the submitted Principal Token scope array
          and the parent's effective Capability Manifest.  If any Check 9
          condition fails, the Registry MUST reject with
          registration_invalid or invalid_delegation_depth when the depth
          limit is exceeded.

     10.  Check 9a. max_delegation_depth Bounds: If the root Principal
          Token for the reconstructed registration chain contains a
          max_delegation_depth claim, the Registry MUST verify that its
          value is an integer in the range 0 through 10 inclusive.  If
          max_delegation_depth is absent from the root Principal Token,
          the Registry MUST treat it as 3 for all subsequent registration
          processing.  If the value exceeds 10 or is a negative integer,
          the Registry MUST reject the registration with
          registration_invalid and MUST include the detail string
          max_delegation_depth exceeds the hard cap of 10 in the error
          response.

     11.  Check 10.  The decoded principal_token payload principal.id MUST
          NOT begin with did:aip:.

     12.  Check 11.  If the synced AIP Namespace Catalog entry for
          identity.type has requires_task_id: true, the decoded
          principal_token payload task_id MUST be non-null and non-empty.

     13.  Check 12. capability_manifest.signature MUST be verifiable
          against the granted_by DID's public key.

     14.  Check 13. identity.version MUST equal 1 and
          identity.previous_key_signature MUST be absent.  Registration
          Envelopes are initial-registration objects only; key rotation is
          processed through PUT /v1/agents/{aid}.

     15.  Check 14a. grant_tier MUST be present and MUST be one of "G1",
          "G2", or "G3".  If grant_tier is absent or has any other value,
          the Registry MUST reject with registration_invalid.

     16.  Check 14b.  The Registry MUST determine the requested security
          Tier as the highest AIP Scope Catalog tier among all active
          scopes in capability_manifest.capabilities.






  Singla                  Expires 15 November 2026               [Page 48]


  Internet-Draft                     AIP                          May 2026


     17.  Check 14c.  The submitted grant_tier MUST satisfy the requested
          security Tier determined in Check 14b.  Tier 1 permits "G1",
          "G2", or "G3".  Tier 2 permits "G2" or "G3" unless the
          Registry's identity_proofing_required_for_tier2 metadata field
          is true, in which case Tier 2 permits only "G3".  Tier 3 permits
          only "G3".  If grant_tier is inconsistent with the requested
          security Tier or the Registry's Tier 2 identity-proofing policy,
          the Registry MUST reject with registration_invalid.

     18.  Check 14d.  If the requested security Tier determined in Check
          14b is 2 or 3, the decoded principal_token payload principal.id
          MUST use the did:web method.  Otherwise, the Registry MUST
          reject with principal_did_method_forbidden.

     19.  Check 14e.  If grant_tier is "G3", the decoded principal_token
          payload MUST include a non-empty acr string and a non-empty amr
          array.  If either claim is absent or empty, the Registry MUST
          reject with identity_proofing_insufficient.

     20.  Check 15.  If the requested security Tier determined in Check
          14b is 2 and identity.model.attestation_hash is absent, the
          Registry SHOULD accept the Registration Envelope, but only if it
          creates a structured registration warning with code equal to
          "model_attestation_missing_tier2", severity equal to "warning",
          source_check equal to "registration_check_15", and issued_at set
          to the Registry's current time.  The warning message MUST state
          that the Tier 2 agent is not cryptographically pinned to a model
          artifact.  The Registry MUST persist this warning in Agent
          Registration Metadata, MUST include it in the successful POST
          /v1/agents response, and MUST return it in subsequent GET /v1/
          agents/{aid} metadata responses while the registered Agent
          Identity Object lacks model.attestation_hash.  The persisted
          warning is the required audit artifact for this condition.  If
          the requested security Tier is 3,
          identity.model.attestation_hash MUST be present and MUST match
          the sha256:<64 lowercase hex characters> pattern.  If the
          requested security Tier is 3 and the field is absent or
          malformed, the Registry MUST reject with registration_invalid.

     On acceptance, the Registry MUST store the reconstructed registration
     chain for the registered AID.  For a direct registration, that chain
     contains the submitted root Principal Token.  For a sub-agent
     registration, it contains the parent's stored registration chain
     followed by the submitted delegated Principal Token.  The Registry
     MUST record the delegated_by field from the decoded principal_token
     payload (or the principal's DID if delegated_by is null) in the
     parent-child delegation index, for use in revocation propagation
     (Section 11.4).



  Singla                  Expires 15 November 2026               [Page 49]


  Internet-Draft                     AIP                          May 2026


     If the synced AIP Namespace Catalog entry for identity.type defines
     an automatic lifecycle expiry rule, the Registry MUST persist the
     resulting lifecycle_expires_at value in its stored registration
     record before accepting the Registration Envelope.  For the Draft-02
     ephemeral namespace, lifecycle_expires_at MUST be no later than the
     earlier of the decoded root Principal Token expires_at value and
     capability_manifest.expires_at.

  6.3.  Error Responses

     All AIP error responses MUST use the format defined in Section 18.1.
     Implementations MUST NOT return HTTP 200 for error conditions.

  7.  Agent Resolution

  7.1.  DID Resolution

     Every registered AID MUST have a corresponding W3C DID Document
     resolvable by a DID resolver that implements the did:aip method
     defined in this section.  The DID Document is derived
     deterministically from the Agent Identity, active Capability
     Manifest, and lifecycle state stored in the authoritative Registry.

     The Registry MUST generate and serve DID Documents from GET /v1/
     agents/{aid} when the Accept: application/did+ld+json or Accept:
     application/did+json header is present.  Without one of these DID-
     specific Accept values, the endpoint returns the default Agent
     Registration Metadata response defined in Section 17.4.

     AIP implementations MUST support DID resolution for at minimum
     did:aip, did:key, and did:web DID methods.  Resolved DID Documents
     MAY be cached for a maximum of 300 seconds.

     DID resolution performed during token validation MUST use an explicit
     timeout.  For any validation step that is REQUIRED because the token
     has security Tier 2 or Tier 3 or because the token contains
     aip_registry, each remote DID resolution attempt MUST time out no
     later than 2 seconds after it is started, and the aggregate wall-
     clock budget for DID resolution across a single token validation
     attempt MUST NOT exceed 5 seconds.  Local non-network resolution,
     such as did:key, SHOULD complete without consuming this remote-
     resolution budget.  Implementations MAY use shorter timeouts, but
     MUST NOT use a zero-duration timeout for a required remote DID
     resolution attempt.

     If DID resolution fails or times out during a REQUIRED validation
     step, implementations MUST treat the result as registry_unavailable
     and MUST reject the operation.  If a Tier 1-only operation performs



  Singla                  Expires 15 November 2026               [Page 50]


  Internet-Draft                     AIP                          May 2026


     Registry Trust Anchoring as a RECOMMENDED check and DID resolution
     times out, the Relying Party MAY either reject with
     registry_unavailable or skip that RECOMMENDED check according to
     local policy.

     If the AID has been revoked, the Registry MUST return deactivated:
     true in _didDocumentMetadata_, per W3C-DID Section 7.1.2.

  7.2.  did:aip Method Resolution

     A did:aip resolver MUST NOT infer the authoritative Registry from the
     namespace or agent-id components of the DID.  The resolver MUST be
     invoked with an authoritative Registry base URI, or MUST obtain one
     from protocol context: the aip_registry claim in a Credential Token,
     the iss or aip_registry value in a Step Execution Token, the root
     principal DID Document's AIPRegistry service entry, or a local trust
     policy that binds the AID namespace to a Registry.  If no
     authoritative Registry can be determined, resolution fails and
     protocol validation that requires the result MUST reject with
     registry_unavailable.

     The resolver's input DID MUST match the did:aip syntax in
     Section 4.1.  A resolver receiving a malformed AID MUST return a DID
     Core resolution result with didResolutionMetadata.error set to
     invalidDid and MUST NOT contact a Registry.

     To resolve a valid AID, the resolver MUST perform the following
     steps:

     1.  Resolve and, when required by the validation context, pin the
         authoritative Registry trust state using the Registry Genesis
         procedure in Section 7.4.

     2.  Percent-encode the complete AID for use as the {aid} path
         parameter according to Section 17.2.

     3.  Send GET /v1/agents/{aid} to the authoritative Registry with
         Accept: application/did+json or Accept: application/did+ld+json.

     4.  If the Registry returns HTTP 404, return a DID resolution result
         with didResolutionMetadata.error set to notFound.

     5.  If the Registry cannot be reached or times out under the limits
         in Section 7.1, return a DID resolution result with
         didResolutionMetadata.error set to registry_unavailable.






  Singla                  Expires 15 November 2026               [Page 51]


  Internet-Draft                     AIP                          May 2026


     6.  If the requested representation is unsupported, return a DID
         resolution result with didResolutionMetadata.error set to
         representationNotSupported.

     7.  On success, return a DID Core resolution result whose
         didDocument.id equals the input AID, whose
         didResolutionMetadata.contentType matches the returned
         representation, and whose didDocumentMetadata contains versionId,
         updated, deactivated, and aip_registry.

     A Registry constructs the did:aip DID Document from its stored
     registration record as follows.  The DID Document id is the AID.  The
     verificationMethod array contains the current active Ed25519 public
     key from the current Agent Identity Object.  The verification method
     id MUST equal <aid>#key-<identity.version>, its controller MUST equal
     the AID, and its publicKeyJwk MUST contain only public JWK members.
     The authentication array MUST contain that verification method
     identifier.  The DID Document controller value MUST equal the active
     Capability Manifest granted_by value.  The
     didDocumentMetadata.versionId value MUST equal the decimal string
     form of identity.version.

     DID URL dereferencing for did:aip supports only the empty fragment
     and key fragments of the form #key-<positive-integer>.  The empty
     fragment dereferences to the DID Document.  A key fragment
     dereferences to the corresponding verification method if the Registry
     retains the requested historical key version at GET /v1/
     agents/{aid}/public-key/{key-id}; otherwise dereferencing returns
     didResolutionMetadata.error set to notFound.  Other fragments MUST
     return notFound.

     The CRUD operations for the did:aip method are:



















  Singla                  Expires 15 November 2026               [Page 52]


  Internet-Draft                     AIP                          May 2026


       +============+==================================================+
       | Operation  | Mechanism                                        |
       +============+==================================================+
       | Create     | POST /v1/agents with a Registration Envelope     |
       |            | that passes Section 6 validation                 |
       +------------+--------------------------------------------------+
       | Read       | GET /v1/agents/{aid}; default metadata response, |
       |            | or DID Document with DID Accept header           |
       +------------+--------------------------------------------------+
       | Update     | PUT /v1/agents/{aid} for key rotation only;      |
       |            | arbitrary DID Document mutation is not supported |
       +------------+--------------------------------------------------+
       | Deactivate | POST /v1/revocations with a valid full_revoke    |
       |            | Revocation Object                                |
       +------------+--------------------------------------------------+

                                    Table 11

     Deactivation is permanent for the affected AID.  After full
     revocation, the Registry MUST return didDocumentMetadata.deactivated
     as true.  The Registry MAY still return the last DID Document and
     MUST continue to serve retained historical public keys for audit and
     signature verification, but Relying Parties MUST reject new protocol
     operations for a deactivated AID during revocation and lifecycle
     validation.

  7.3.  DID Document Structure

     A conformant did:aip DID Document MUST include @context, id,
     verificationMethod, authentication, and controller.  See the
     canonical example in the repository at _examples/did-document.json_.
     Method operations and DID URL dereferencing rules are defined in
     Section 7.2.

     A principal that authorises agents for Tier 2 or Tier 3 operations
     MUST use the did:web DID method, and that principal's DID Document
     MUST include an AIPRegistry service entry in its service array.
     Principals MUST NOT use the did:aip method anywhere in the protocol.

       {
         "id": "did:web:acme.com#aip-registry",
         "type": "AIPRegistry",
         "serviceEndpoint": "https://registry.acme.com"
       }

     The serviceEndpoint MUST be an HTTPS URI pointing to the base URL of
     the authoritative AIP Registry for agents delegated by this
     principal.  The type MUST be exactly "AIPRegistry" (case-sensitive).



  Singla                  Expires 15 November 2026               [Page 53]


  Internet-Draft                     AIP                          May 2026


     For principals using did:key: an AIPRegistry service entry cannot be
     declared (DID Key documents have no service array).  did:key
     principals MUST NOT authorise Tier 2 or Tier 3 operations.

     For principals using any W3C DID method other than did:web or
     did:aip, authorisation is limited to Tier 1.  Even if such a DID
     method supports service entries, this specification does not permit
     it for Tier 2 or Tier 3 principal authorisation.  For did:web
     principals, the AIPRegistry service entry is REQUIRED when the
     principal authorises any agent with Tier 2 or Tier 3 scopes.  It is
     OPTIONAL for principals authorising only Tier 1 agents.

  7.4.  Registry Genesis

     Registry Genesis is the one-time initialisation procedure by which a
     new AIP Registry establishes its stable service identifier, generates
     its initial trust keys, and publishes discovery and trust metadata.
     It MUST be performed before the Registry serves any requests.

  7.4.1.  Key Generation

     The Registry MUST generate a fresh Ed25519 trust keypair at first
     boot.  The private key MUST be stored encrypted at rest (AES-256-GCM
     or an equivalent at-rest key-protection control satisfying
     Section 21.4).  The corresponding public key is published in the
     initial Registry Trust Record.  Separate active verification keys for
     CRL documents (Section 11.3) and Step Execution Tokens are
     RECOMMENDED so that routine operational-key rotation does not require
     trust-root rotation.

  7.4.2.  Registry ID Establishment

     The Registry MUST establish a stable registry_id for the Registry
     service.  The registry_id MUST be an HTTPS URI under the Registry
     operator's control.  The RECOMMENDED value is the origin that serves
     /v1/registry-metadata.

       https://registry.example.com

     The registry_id identifies the Registry service, not a single signing
     key.  It MUST remain stable across planned key rotation.  At most one
     active registry_id MUST exist per Registry deployment at any time.









  Singla                  Expires 15 November 2026               [Page 54]


  Internet-Draft                     AIP                          May 2026


  7.4.3.  Self-Registration Exemption

     The Registry service identifier MUST NOT be created via POST /v1/
     agents.  Instead, the Registry MUST persist its registry_id and trust
     keys directly to its own data store during genesis.  The following
     Registration Envelope checks (Section 6.2) are explicitly
     inapplicable to the Registry service:

     *  *Check 8* (principal_token validation) — the Registry has no human
        principal and MUST NOT carry a principal delegation chain.

     *  *Check 4* (duplicate AID rejection) — genesis is idempotent; if a
        registry_id already exists in the data store the existing record
        MUST be used and genesis MUST NOT overwrite it.

  7.4.4.  Registry Metadata Publication

     The Registry MUST publish Registry Metadata at the following endpoint
     relative to its registry_id origin:

     GET /v1/registry-metadata

     The response MUST be a JSON object containing:

     +===================================+=======+========+==============+
     |Field                              |Type   |Required|Description   |
     +===================================+=======+========+==============+
     |registry_id                        |string |REQUIRED|Stable HTTPS  |
     |                                   |       |        |identifier    |
     |                                   |       |        |for the       |
     |                                   |       |        |Registry      |
     |                                   |       |        |service       |
     +-----------------------------------+-------+--------+--------------+
     |registry_name                      |string |REQUIRED|Human-        |
     |                                   |       |        |readable      |
     |                                   |       |        |Registry name |
     |                                   |       |        |(maxLength:   |
     |                                   |       |        |128)          |
     +-----------------------------------+-------+--------+--------------+
     |aip_version                        |string |REQUIRED|The AIP       |
     |                                   |       |        |protocol      |
     |                                   |       |        |compatibility |
     |                                   |       |        |version this  |
     |                                   |       |        |Registry      |
     |                                   |       |        |conforms to;  |
     |                                   |       |        |not the       |
     |                                   |       |        |Internet-     |
     |                                   |       |        |Draft         |



  Singla                  Expires 15 November 2026               [Page 55]


  Internet-Draft                     AIP                          May 2026


     |                                   |       |        |revision      |
     +-----------------------------------+-------+--------+--------------+
     |registry_trust_uri                 |string |REQUIRED|URI of the    |
     |                                   |       |        |current       |
     |                                   |       |        |Registry      |
     |                                   |       |        |Trust Record  |
     +-----------------------------------+-------+--------+--------------+
     |endpoints                          |object |REQUIRED|Map of        |
     |                                   |       |        |service names |
     |                                   |       |        |to relative   |
     |                                   |       |        |paths or      |
     |                                   |       |        |absolute      |
     |                                   |       |        |HTTPS URIs    |
     +-----------------------------------+-------+--------+--------------+
     |enterprise_idp_federation_supported|boolean|OPTIONAL|True only     |
     |                                   |       |        |when the      |
     |                                   |       |        |Registry      |
     |                                   |       |        |supports the  |
     |                                   |       |        |Enterprise    |
     |                                   |       |        |IdP           |
     |                                   |       |        |Federation    |
     |                                   |       |        |Profile in    |
     |                                   |       |        |Section       |
     |                                   |       |        |8.4.5.        |
     |                                   |       |        |SHOULD be     |
     |                                   |       |        |present in    |
     |                                   |       |        |all Registry  |
     |                                   |       |        |Metadata      |
     |                                   |       |        |documents.    |
     |                                   |       |        |Absence is    |
     |                                   |       |        |treated as    |
     |                                   |       |        |equivalent to |
     |                                   |       |        |false.        |
     |                                   |       |        |Gateways that |
     |                                   |       |        |surface this  |
     |                                   |       |        |capability    |
     |                                   |       |        |through       |
     |                                   |       |        |/.well-known/ |
     |                                   |       |        |oauth-        |
     |                                   |       |        |protected-    |
     |                                   |       |        |resource      |
     |                                   |       |        |SHOULD ensure |
     |                                   |       |        |the value is  |
     |                                   |       |        |consistent    |
     |                                   |       |        |with the      |
     |                                   |       |        |Registry's    |
     |                                   |       |        |declared      |
     |                                   |       |        |support in    |



  Singla                  Expires 15 November 2026               [Page 56]


  Internet-Draft                     AIP                          May 2026


     |                                   |       |        |this          |
     |                                   |       |        |document.  A  |
     |                                   |       |        |mismatch      |
     |                                   |       |        |between the   |
     |                                   |       |        |two documents |
     |                                   |       |        |MUST be       |
     |                                   |       |        |treated as a  |
     |                                   |       |        |Registry      |
     |                                   |       |        |configuration |
     |                                   |       |        |error.        |
     +-----------------------------------+-------+--------+--------------+

                                    Table 12

     The _endpoints_ object MUST include at minimum:

           +=============+=========================================+
           | Key         | Description                             |
           +=============+=========================================+
           | agents      | Base path for agent endpoints (e.g.,    |
           |             | /v1/agents)                             |
           +-------------+-----------------------------------------+
           | crl         | Preferred CRL retrieval URI.  This      |
           |             | value MAY be the origin path /v1/crl or |
           |             | an absolute HTTPS CDN/distribution URI. |
           +-------------+-----------------------------------------+
           | revocations | Revocation submission path (e.g., /v1/  |
           |             | revocations)                            |
           +-------------+-----------------------------------------+

                                    Table 13

     First-contact bootstrapping: On first contact with a Registry,
     Relying Parties MUST:

     *  Fetch /v1/registry-metadata over HTTPS.

     *  Verify that the response registry_id matches the Registry URI
        established via the root principal DID Document when such a DID
        binding is available.  Unless otherwise specified, this comparison
        MUST use origin comparison per [RFC6454] (scheme + host + port).

     *  Fetch the Registry Trust Record from registry_trust_uri.

     *  Pin the registry_id, the trusted Registry Trust Record version,
        and the trust keys from that record locally.





  Singla                  Expires 15 November 2026               [Page 57]


  Internet-Draft                     AIP                          May 2026


     *  Use the accepted Registry Trust Record's signed endpoints object
        as the authoritative endpoint map for Registry interactions.  The
        Registry Metadata endpoints object is a bootstrap hint and MUST
        NOT override a valid signed Registry Trust Record.

     *  On subsequent contacts, use the versioned trust-update procedure
        in Section 7.4.7.1 before updating the local trust state.

     Endpoint values that begin with / are resolved relative to
     registry_id.  Absolute endpoint values MUST use HTTPS.  The
     endpoints.crl value MAY use a different HTTPS origin from registry_id
     so that CRL documents can be served from a CDN or distributed object
     store.  A different CRL origin does not identify a different
     Registry; verifiers bind CRL documents to the Registry by verifying
     the CRL signature against the accepted Registry Trust Record version
     current at CRL issuance time.

     The registry_id identifies the Registry instance and MUST remain
     stable across planned Registry key rotation.  Planned key rotation
     updates the Registry Trust Record and the Registry's active
     verification keys while preserving the same registry_id.  Emergency
     compromise recovery is handled separately under Section 7.4.7.2.

     The Registry Metadata document is discovery metadata.  The canonical
     trust state for a Registry is defined by its Registry Trust Record,
     not by the Registry Metadata document itself.

  7.4.5.  Registry Trust Record

     A Registry Trust Record is the canonical versioned trust metadata
     object for a Registry.  It MUST be published at:

         +========+==========================+======================+
         | Method | Path                     | Description          |
         +========+==========================+======================+
         | GET    | /v1/registry-trust/      | Current Registry     |
         |        | current                  | Trust Record         |
         +--------+--------------------------+----------------------+
         | GET    | /v1/registry-            | Immutable Registry   |
         |        | trust/{version}          | Trust Record for the |
         |        |                          | specified version    |
         +--------+--------------------------+----------------------+

                                   Table 14

     The Registry Trust Record MUST use a detached-signature structure
     consisting of a signed object and a signatures array.  The signed
     object MUST include at minimum:



  Singla                  Expires 15 November 2026               [Page 58]


  Internet-Draft                     AIP                          May 2026


     *  registry_id

     *  version

     *  issued_at

     *  expires_at

     *  discovery_uri

     *  endpoints

     *  trust_signature_threshold

     *  trusted_keys

     *  active_verification_keys

     The canonical signing input is the RFC 8785 JCS serialisation of the
     signed object only.  Signature verification MUST ignore the
     signatures array except as the container for detached signatures over
     that signed object.

     Verifiers use the latest trusted Registry Trust Record for current
     Registry interactions.  For historical verification of Step Execution
     Tokens, CRLs, or signed notifications, verifiers MUST use the
     Registry Trust Record version that was current at artifact issuance
     time.  The trusted_keys set governs trust-record acceptance, while
     active_verification_keys governs which runtime keys are valid for
     Registry-signed artifacts issued under that trust-record version.

     Each entry in active_verification_keys.step_execution,
     active_verification_keys.crl, and
     active_verification_keys.notifications MUST be an Ed25519 public JWK
     containing kty, crv, x, and keyid.  A verifier MUST NOT treat a bare
     key identifier as sufficient for runtime artifact verification; the
     accepted Registry Trust Record version must provide the public key
     material used to verify the artifact signature.

     For CRL retrieval, verifiers MUST use signed.endpoints.crl from the
     accepted Registry Trust Record, resolving it according to the
     endpoint rules above.  The unsigned Registry Metadata endpoints.crl
     value MAY be used only to locate bootstrap metadata before the
     Registry Trust Record is accepted.

     Historical Registry Trust Records MUST remain retrievable for at
     least the maximum lifetime of Step Execution Tokens and CRL artifacts
     plus a 30-day audit margin.



  Singla                  Expires 15 November 2026               [Page 59]


  Internet-Draft                     AIP                          May 2026


  7.4.6.  Single-Instance Constraint

     Each Registry deployment MUST have exactly one active Registry ID.
     Provisioning a second Registry ID within the same deployment MUST be
     treated as a fatal configuration error.  Horizontal scaling and high-
     availability deployments MUST share a single Registry ID and trust
     state.

  7.4.7.  Registry Key Rotation

     AIP defines two Registry key rotation paths:

     *  *Planned rotation:* continuity-preserving rotation in which the
        Registry keeps the same registry_id and publishes a new Registry
        Trust Record version.

     *  *Emergency re-bootstrap:* continuity-breaking recovery for
        suspected key compromise or loss of the retiring private key.

     Validators bootstrapping trust in a Registry MUST fetch and pin the
     current Registry Trust Record before processing any Step Execution
     Tokens or CRL documents signed by that Registry.  Cached trust state
     MUST NOT be used beyond the trust record's expires_at without
     refresh.

     A Step Execution Token is not a trust-bootstrap artifact.  Relying
     Parties MUST NOT establish first-contact Registry trust from a SET
     received in an application request.  A SET whose iss Registry ID is
     unknown, unpinned, expired, or missing the locally retained Registry
     Trust Record version named by the SET protected header aip_trv MUST
     be rejected with registry_untrusted.  An implementation MAY perform
     first-contact bootstrap or sequential trust update as a separate pre-
     validation operation, but it MUST complete and pin the accepted trust
     state before reprocessing the SET.

  7.4.7.1.  Planned Rotation

     During planned rotation, the Registry MUST publish a new immutable
     Registry Trust Record whose signed.version is exactly one greater
     than the previously trusted version and whose signed.registry_id
     matches the existing pinned registry_id.

     The signed.trust_signature_threshold value defines the minimum number
     of signatures from signed.trusted_keys required for ordinary
     acceptance of a Registry Trust Record.  Implementations MAY require a
     higher threshold than 1 for high-assurance deployments, but they MUST
     still preserve the overlapping-signature rule below during planned
     rotation.



  Singla                  Expires 15 November 2026               [Page 60]


  Internet-Draft                     AIP                          May 2026


     Planned rotation MUST use overlapping trust signatures.  A new
     Registry Trust Record version MUST satisfy the threshold rules in
     both the currently pinned and the candidate new trust record.  At a
     minimum, a planned rotation update MUST be signed by:

     1.  at least one key trusted in the currently pinned Registry Trust
         Record; and

     2.  at least one key trusted in the new Registry Trust Record.

     If the Registry Metadata document's registry_trust_uri does not share
     the same origin as registry_id, the Relying Party MUST treat the
     Registry as untrusted unless an explicit trust policy permits that
     alternate trust-record origin.

     A Relying Party that has pinned trust version N MUST update
     sequentially.  It MUST fetch and validate version N+1 before
     accepting version N+2 or later.

     This sequential trust-update model is intentionally similar to
     repository root update patterns in The Update Framework [TUF], where
     clients advance trust state one version at a time to resist rollback
     and mix-and-match attacks.

     1.  The fetched record's signed.registry_id MUST match the pinned
         value.

     2.  The fetched record's signed.version MUST equal the pinned version
         plus exactly 1.

     3.  The fetched record's signatures MUST satisfy the overlapping-
         signature rule above.

     4.  The fetched record's expires_at MUST be in the future.

     5.  The fetched record MUST NOT be older than or equal to any
         previously accepted version for that registry_id.

     If all checks succeed, the Relying Party MAY replace its pinned trust
     state with the new Registry Trust Record while retaining the prior
     trust records for historical verification.

     Historical Step Execution Tokens and CRL documents signed before the
     rotation remain valid for their stated _exp_ period only.  Relying
     Parties MUST verify such historical artifacts against the Registry
     Trust Record version that was current at issuance time; they MUST NOT
     re-verify them against the newest trust record automatically.




  Singla                  Expires 15 November 2026               [Page 61]


  Internet-Draft                     AIP                          May 2026


  7.4.7.2.  Emergency Re-Bootstrap

     This distinction between planned rollover and emergency continuity-
     breaking recovery is similar in spirit to DNSSEC trust anchor
     rollover guidance in [RFC5011], where automated trust continuity and
     exceptional recovery are treated as different operational cases.

     If a Registry Trust Record update cannot satisfy the planned rotation
     checks, or if the retiring trust key is suspected compromised or
     unavailable, the event MUST be treated as an emergency re-bootstrap.

     1.  Relying Parties that have pinned Registry trust state and
         subsequently receive discovery or trust metadata that does not
         satisfy the planned-rotation checks above MUST treat this as a
         potential MITM condition.

     2.  Relying Parties MUST NOT use the new trust state automatically.
         They MUST halt Registry-dependent operations and require explicit
         re-bootstrap or out-of-band operator confirmation before re-
         pinning.

     3.  Emergency re-bootstrap is continuity-breaking by design.
         Automatic verifier acceptance rules for planned rotation do not
         apply.

     4.  Historical Step Execution Tokens and CRL documents signed by the
         previous Registry trust state remain valid for their stated _exp_
         period only.  Relying Parties MUST verify historical artifacts
         against the trust record version that was current at issuance
         time; they MUST NOT re-verify them against the emergency
         replacement trust state.

  7.5.  AIP Gateway Protected Resource Metadata

     Any MCP gateway that enforces AIP authentication for tool listing or
     tool execution MUST publish OAuth Protected Resource Metadata
     [RFC9728] using the registered oauth-protected-resource well-known
     URI suffix:

     https://{gateway-host}/.well-known/oauth-protected-resource

     AIP does not define or require an AIP-specific well-known URI suffix
     for gateway discovery.  The response MUST be a JSON object conforming
     to RFC 9728 and containing the following fields:







  Singla                  Expires 15 November 2026               [Page 62]


  Internet-Draft                     AIP                          May 2026


     {
       "resource": "https://gateway.example.com/",
       "authorization_servers": ["https://registry.example.com"],
       "scopes_supported": ["email.read", "calendar.read"],
       "bearer_methods_supported": ["header"],
       "dpop_signing_alg_values_supported": ["EdDSA"],
       "dpop_bound_access_tokens_required": true,
       "resource_name": "Example AIP MCP Gateway",
       "resource_documentation": "https://gateway.example.com/docs"
     }

     resource  REQUIRED.  The gateway protected resource identifier.  It
        MUST be an HTTPS URL with no fragment, as defined by [RFC9728].

     authorization_servers  REQUIRED for AIP gateways.  The array MUST
        contain at least one AIP Registry OAuth authorization-server
        issuer identifier acceptable for this protected resource.

     scopes_supported  RECOMMENDED.  When present, values MUST be AIP
        scope strings from the synced AIP Scope Catalog or accepted local
        extension policy.

     bearer_methods_supported  REQUIRED for AIP gateways that accept non-
        DPoP Bearer tokens and MUST include "header" when present.  AIP
        uses the registered Bearer authentication scheme for requests that
        do not require proof-of-possession and the registered DPoP
        authentication scheme for DPoP-bound tokens.

     dpop_signing_alg_values_supported  REQUIRED when any advertised scope
        or endpoint requires DPoP, and MUST include "EdDSA".

     dpop_bound_access_tokens_required  REQUIRED when the gateway requires
        DPoP-bound access tokens for all requests to the protected
        resource.  If omitted or false, clients MUST still apply AIP DPoP
        requirements derived from the requested scope Tier, Scope Catalog
        metadata, and endpoint policy.

     tls_client_certificate_bound_access_tokens  REQUIRED and set to true
        when the gateway enforces AIP Tier 3 mTLS-bound access tokens for
        the protected resource.

     *Endpoint Requirements:*

     1  The /.well-known/oauth-protected-resource endpoint MUST respond to
        unauthenticated HTTP GET requests.  Authentication MUST NOT be
        required to retrieve the Protected Resource Metadata document.





  Singla                  Expires 15 November 2026               [Page 63]


  Internet-Draft                     AIP                          May 2026


     2  The response MUST use HTTP status 200 and Content-Type:
        application/json.

     3  The response SHOULD include a Cache-Control header with a max-age
        value between 60 and 300 seconds.  Clients MUST NOT cache the
        Protected Resource Metadata document for longer than 300 seconds.

     4  *Consistency Constraint:* If a gateway advertises Tier 2 or Tier 3
        scopes in scopes_supported, or if local endpoint policy marks the
        protected resource as Tier 2 or Tier 3, the gateway MUST either
        set dpop_bound_access_tokens_required to true or document per-
        scope DPoP requirements through Registry policy.  A client MUST
        treat contradictory metadata as gateway_config_invalid.

     5  For stateless gateway deployments (Section 8.2.1), the gateway
        MUST NOT serve stale Protected Resource Metadata; the document
        MUST reflect the currently active resource configuration from the
        shared configuration store.

     MCP clients that discover a gateway through OAuth Protected Resource
     Metadata SHOULD fetch this document before tool listing or tool
     execution.  If the document is absent, malformed, or does not
     identify an acceptable AIP Registry authorization server, an AIP-
     aware MCP client MUST NOT assume that unauthenticated tool access is
     permitted.

  8.  Credential Tokens

  8.1.  Credential Token Transport and Version Header

     The Credential Token JWT header and payload fields are defined in
     Section 5.4.  This section defines only the HTTP transport profile,
     version-header requirements, issuance lifetime rules, and refresh
     behavior for those tokens.

     An AIP Credential Token for a request that does not require proof-of-
     possession is transmitted as an HTTP Authorization header using the
     registered Bearer authentication scheme [RFC6750]:

     EXAMPLE (informative):

      Authorization: Bearer <token>
      X-AIP-Version: 0.3

     For interactions requiring Proof-of-Possession, the Credential Token
     is transmitted using the registered DPoP authentication scheme
     [RFC9449] and the request also carries a DPoP proof JWT:




  Singla                  Expires 15 November 2026               [Page 64]


  Internet-Draft                     AIP                          May 2026


     EXAMPLE (informative):

      Authorization: DPoP <token>
      DPoP: <dpop-proof>
      X-AIP-Version: 0.3

     The X-AIP-Version HTTP header MUST carry the full protocol version
     string, identical to the aip_version JWT claim.  For this
     specification, the value MUST be "0.3".  This value is the AIP
     protocol compatibility version defined in Section 20, not the
     Internet-Draft revision suffix.  Implementations MUST reject requests
     with unsupported_version when the X-AIP-Version header is absent,
     carries an unsupported value, or does not match the token aip_version
     claim.

     Every AIP-aware HTTP response to an AIP protocol request MUST include
     an X-AIP-Version response header containing the AIP protocol
     compatibility version used to interpret the request and generate the
     response.  For responses conforming to this specification, the value
     MUST be "0.3".  This requirement applies to successful responses and
     error responses, including responses that reject a request with
     unsupported_version.  When a request is rejected because the
     requested version is unsupported, the responder MUST set X-AIP-
     Version to a protocol version it supports for that endpoint and
     SHOULD include X-AIP-Supported-Versions with a comma-separated list
     of supported AIP protocol versions.

  8.2.  Token Issuance

     Implementations MUST enforce the following maximum Credential Token
     lifetimes.  The effective TTL limit for a token is the lowest
     applicable limit from this table across all requested scopes.



















  Singla                  Expires 15 November 2026               [Page 65]


  Internet-Draft                     AIP                          May 2026


        +===============+============================================+
        | Scope         | Maximum TTL                                |
        | Category      |                                            |
        +===============+============================================+
        | Tier 1 scope  | 3600 seconds, unless the synced AIP Scope  |
        |               | Catalog entry sets a lower ttl_max_seconds |
        +---------------+--------------------------------------------+
        | Tier 2 scope  | 300 seconds, unless the synced AIP Scope   |
        |               | Catalog entry sets a lower ttl_max_seconds |
        +---------------+--------------------------------------------+
        | Tier 3 scope  | 300 seconds, unless the synced AIP Scope   |
        |               | Catalog entry sets a lower ttl_max_seconds |
        +---------------+--------------------------------------------+
        | Any requested | The ttl_max_seconds value in the synced    |
        | scope         | AIP Scope Catalog entry for that scope,    |
        |               | capped by the Tier ceiling above           |
        +---------------+--------------------------------------------+
        | Multiple      | The lowest ttl_max_seconds value across    |
        | scopes in one | all requested scopes                       |
        | token         |                                            |
        +---------------+--------------------------------------------+

                                   Table 15

     When a token contains multiple scopes, the most restrictive TTL
     applies.  Zero-duration and negative-duration tokens (where exp <=
     iat) MUST be rejected.  A synced AIP Scope Catalog entry for a
     standard or extension scope MUST NOT advertise a ttl_max_seconds
     value greater than the ceiling for that scope's Tier.  A token
     containing a scope whose active catalog entry is missing, inactive,
     or exceeds its Tier ceiling MUST be rejected with invalid_scope or
     invalid_token as applicable to the validation step.

     A token's security Tier is determined by its highest-risk scope
     (Section 3.2).  A token containing one Tier 2 scope and any number of
     Tier 1 scopes is a Tier 2 token in its entirety.  Implementations
     MUST NOT derive Tier from the majority of scopes or from the first
     scope in the array.

  8.2.1.  Token Cache Requirements for Stateless Deployments

     AIP Registries and Relying Parties operating in stateless transport
     environments, including MCP stateless transport [MCP-STATELESS], or
     horizontally-scaled deployments MUST store validated Credential Token
     cache entries in a shared, externally-accessible store, such as Redis
     or a distributed key-value store, that is accessible to all instances
     that may validate tokens for the same AID.  Local in-process or
     filesystem-backed caches are PERMITTED only in single-instance



  Singla                  Expires 15 November 2026               [Page 66]


  Internet-Draft                     AIP                          May 2026


     development deployments and MUST NOT be used in a Production
     Deployment as defined in Section 3.

     A validation cache entry MUST be keyed by SHA-256(exact-compact-
     token), not by jti alone.  The cache entry MUST include:

     *  the token iss and jti for replay-cache correlation;

     *  the token exp as the maximum cache TTL;

     *  the cached Registry-dependent validation subresults and their
        freshness sources;

     *  the set of validation step identifiers whose results were cached;
        and

     *  the validated AIP Tier.

     A cache entry is an optimization for previously completed validation,
     not a replacement for the validation algorithm.  Implementations MAY
     reuse cached Registry-dependent validation results only when the
     token's Tier and the relevant validation step permit bounded
     staleness.  For Tier 2 and Tier 3 tokens, a cached accepted result
     MUST NOT bypass the live revocation lookup required by Section 11.4
     and Section 9.10.  Per-request checks that are not cacheable,
     including proof-of-possession, mTLS, audience matching, expiration,
     and replay policy, remain in force for every interaction.  A cached
     accepted result MUST NOT cause a token whose (iss, jti) pair has
     already been consumed to be accepted again.  This cache prevents
     redundant Registry round-trips only for validation results whose
     freshness rules allow reuse.

  8.3.  Token Refresh and Long-Running Tasks

  8.3.1.  Agent Self-Refresh

     An AIP agent holds its own Ed25519 private key and MAY issue new
     Credential Tokens at any time, provided the Principal Token(s) in its
     delegation chain (aip_chain) remain valid.  There is no refresh token
     in AIP - the agent's signing key IS the refresh credential.

     An agent self-refresh involves: issuing a new Credential Token with a
     new jti, a fresh iat, and a new exp within TTL limits.  The aip_chain
     content remains unchanged until the Principal Tokens within it
     expire.






  Singla                  Expires 15 November 2026               [Page 67]


  Internet-Draft                     AIP                          May 2026


     Agents MUST NOT re-use the same jti when issuing a fresh token.  Each
     issued Credential Token MUST have a unique jti across all tokens
     issued by that agent AID.  This uniqueness requirement is independent
     of aip_chain, principal DID, registration grant, scope set, or
     audience.  An agent delegated by multiple principals MUST still
     maintain a single jti uniqueness domain for its issuer AID.

  8.3.2.  Pre-emptive Refresh Requirements

     Agents MUST implement pre-emptive refresh to avoid mid-task token
     expiry.  An agent MUST begin issuing a replacement Credential Token
     before the current token expires.  The refresh threshold is derived
     from the token's effective TTL, not from a fixed Tier label:

     effective_ttl_seconds = exp - iat

     refresh_lead_seconds =
       max(1, min(
         300,
         max(30, ceiling(effective_ttl_seconds * 0.10)),
         floor(effective_ttl_seconds / 2)
       ))

     begin refresh when (exp - now) <= refresh_lead_seconds

     This formula preserves the former 300-second refresh lead for a
     3600-second catalog TTL and the former 30-second refresh lead for a
     300-second catalog TTL, while remaining valid for future catalog TTL
     values.

     Implementations MUST NOT wait for a token rejection (token_expired)
     before refreshing.  Waiting for rejection creates a gap in execution
     continuity and may leave in-progress Tier 2 operations without valid
     authority.

     Relying Parties MUST NOT reject a token solely because a newer token
     exists for the same agent.  Each token is independently valid for its
     own iat to exp window.

     For real-time streaming interactions (e.g., a long-running web
     socket), the agent SHOULD renegotiate the session with a fresh
     Credential Token before the current token's expiry rather than
     waiting for mid-stream rejection.








  Singla                  Expires 15 November 2026               [Page 68]


  Internet-Draft                     AIP                          May 2026


  8.3.3.  Delegation Chain Expiry

     When a Principal Token in the aip_chain expires, the Credential Token
     becomes structurally invalid at validation Step 8h regardless of the
     Credential Token's own exp.  This is because the delegation authority
     itself has lapsed.

     When a delegation chain expires:

     1  The agent MUST NOT issue new Credential Tokens referencing the
        expired aip_chain (even if the agent's own exp is still in the
        future).

     2  The agent MUST obtain a fresh delegation from its parent (or from
        the root principal for depth-0 agents) via the AIP-GRANT flow or
        sub-agent delegation flow.

     3  Once a fresh delegation is established and registered, the agent
        may resume issuing Credential Tokens.

     Relying Parties that receive a token where Step 8h fails MUST return
     chain_token_expired.  Agents receiving this error MUST re-establish
     their delegation rather than merely refreshing their Credential
     Token.  AIP does not define a separate on-wire error code for
     "delegation refresh required"; chain renewal is the required agent-
     side handling of chain_token_expired.

     *Anticipatory chain refresh:* Agents SHOULD monitor the expires_at
     timestamps of all Principal Tokens in their aip_chain.  When the
     nearest expiry is within 10% of the total delegation validity period
     (or 24 hours, whichever is smaller), the agent SHOULD proactively
     initiate a delegation renewal.

  8.3.4.  Interaction with Approval Envelopes

     Approval Envelopes are specifically designed to decouple human
     approval timing from token TTL constraints.  The following rules
     govern their interaction:

     1  An Approval Envelope's approval_window_expires_at is independent
        of any Credential Token TTL.  Envelopes may remain in
        pending_approval status for hours while catalog-derived Credential
        Token TTLs apply only at execution time.

     2  When an agent claims an Approval Step, it MUST present a
        Credential Token that is valid at the time of the claim.  The
        token TTL for a step-claim follows the same Section 8.2 catalog-
        derived rules as for any other interaction involving those scopes.



  Singla                  Expires 15 November 2026               [Page 69]


  Internet-Draft                     AIP                          May 2026


     3  Long-running workflows where steps are separated by hours or days
        require the agent to issue a fresh Credential Token for each step
        claim.  This is intentional - the agent's authority must be re-
        verified at each step, not just at envelope creation time.

     4  If an agent's delegation chain expires between envelope approval
        and step execution, the agent MUST renew its delegation before
        claiming any remaining steps.  The Approval Envelope itself
        remains valid - only the execution credential needs renewal.

     5  An agent MUST NOT pre-issue step-claim Credential Tokens for all
        steps at envelope approval time.  Tokens MUST be issued at
        execution time so that revocation checks (Section 9 Step 7) are
        performed against the current Registry state.

  8.4.  Token Exchange for MCP

  8.4.1.  Overview

     An AIP agent MAY exchange its Credential Token for a scoped access
     token targeting a specific MCP server or OAuth-protected resource.
     The exchange is performed at the Registry's token endpoint .

  8.4.2.  Exchange Request

     The agent sends an RFC 8693 token exchange request:

      POST /v1/oauth/token HTTP/1.1
      Content-Type: application/x-www-form-urlencoded
      DPoP: <DPoP proof JWT>

      grant_type=urn:ietf:params:oauth:grant-type:token-exchange
      &subject_token=<AIP Credential Token>
      &subject_token_type=urn:ietf:params:oauth:token-type:jwt
      &resource=https://mcp-server.example.com/
      &scope=email.read calendar.read

     Normative requirements:

     1  grant_type MUST be urn:ietf:params:oauth:grant-type:token-
        exchange.

     2  subject_token MUST be a valid AIP Credential Token.

     3  subject_token_type MUST be urn:ietf:params:oauth:token-type:jwt.






  Singla                  Expires 15 November 2026               [Page 70]


  Internet-Draft                     AIP                          May 2026


     4  resource MUST be present per RFC 8707 [RFC8707], identifying the
        target resource server.  For OAuth-protected resources, the value
        MUST be an RFC 9728 [RFC9728] resource identifier.

     5  scope MUST use AIP scope strings from the synced AIP Scope Catalog
        or accepted local extension policy.  The requested scopes MUST be
        a subset of the Credential Token's aip_scope.

     6  DPoP proof [RFC9449] MUST be included, binding the exchange to the
        agent's key material.

  8.4.3.  Exchange Validation

     The Registry (as OAuth AS) MUST:

     1  Validate the subject_token using the full validation algorithm.

     2  Verify the DPoP proof binds to the agent's public key.

     3  Verify the requested scope is a subset of the subject_token's
        aip_scope (attenuation only, never expansion).

     4  Verify the resource identifies a registered MCP server or OAuth-
        protected resource.  The Registry MUST perform this check using at
        least one of the following mechanisms:

        *  match the resource URI against a Registry-local registration
           record for an MCP server or protected resource; or

        *  obtain the resource's Protected Resource Metadata using RFC
           9728 [RFC9728] and verify that the returned resource metadata
           value is the same resource identifier as the requested
           resource.

        When RFC 9728 metadata is used, the metadata MUST identify an
        authorization server acceptable to the Registry, either by listing
        the Registry's OAuth authorization-server issuer identifier in
        authorization_servers or by satisfying an equivalent local trust
        policy.  The Registry MUST reject with invalid_target if metadata
        retrieval fails, the returned resource value does not match the
        requested resource, the resource is not locally registered, or no
        acceptable authorization server relationship is established.

     5  Issue an access token with:

        *  aud set to the resource URI

        *  scope set to the granted scopes



  Singla                  Expires 15 November 2026               [Page 71]


  Internet-Draft                     AIP                          May 2026


        *  sub set to the agent's AID

        *  act.sub set to the root principal's DID (actor chain per
           [RFC8693] §4.1)

        *  TTL <= the remaining TTL of the subject_token

     6  The access token MUST be a JWT per RFC 9068 [RFC9068].

  8.4.4.  Exchange Response

     EXAMPLE (informative):

      {
        "access_token": "<JWT>",
        "token_type": "DPoP",
        "expires_in": 300,
        "scope": "email.read calendar.read",
     "issued_token_type": "urn:ietf:params:oauth:token-type:access_token"
      }

  8.4.5.  Enterprise IdP Federation Profile

     When the target resource in a token exchange request is registered in
     the Registry with enterprise_idp_required: true (see Section 17.13),
     the AIP Registry acting as intermediary MUST perform a secondary
     token exchange with the configured Enterprise IdP.  The Registry MUST
     NOT perform the enterprise IdP leg for resources registered with
     enterprise_idp_required: false or with enterprise_idp_required
     absent.  Enterprise integrations such as Microsoft Entra Agent ID
     [MS-ENTRAAGENTID] can use this profile when the resource registration
     record requires it.

     1  The AIP Registry validates the inbound AIP Credential Token per
        Section 9.

     2  The Registry constructs a signed JWT assertion using its
        registered client identity with the enterprise IdP.  The assertion
        MUST include:

        *  iss: the AIP Registry's client_id registered with the
           enterprise IdP;

        *  sub: the agent's AID;

        *  aud: the enterprise IdP token endpoint URI;





  Singla                  Expires 15 November 2026               [Page 72]


  Internet-Draft                     AIP                          May 2026


        *  aip_sub_principal: the root Principal Token principal.id value
           from the validated aip_chain;

        *  aip_scopes: the validated aip_scope values from the Credential
           Token.

     3  The Registry submits this assertion to the enterprise IdP token
        endpoint using grant_type=urn:ietf:params:oauth:grant-type:jwt-
        bearer per RFC 7523 [RFC7523] or
        grant_type=urn:ietf:params:oauth:grant-type:token-exchange per RFC
        8693 [RFC8693].

     4  The enterprise IdP evaluates the request against its Conditional
        Access, ABAC, and equivalent enterprise access policies using
        aip_sub_principal as the human or organizational principal context
        and the agent AID as the client identity.

     5  On success, the enterprise IdP issues an access token scoped to
        the target resource.

     6  The AIP Registry returns the enterprise-issued token in the token
        exchange response.

  8.4.5.1.  Enterprise Assertion JWT Schema

     The JWT assertion constructed by the Registry for the enterprise IdP
     token endpoint MUST contain the following payload fields:

     +===================+=========+==========+=========================+
     | Field             | Type    | Required | Constraints             |
     +===================+=========+==========+=========================+
     | iss               | string  | REQUIRED | MUST be the AIP         |
     |                   |         |          | Registry's client_id as |
     |                   |         |          | registered with the     |
     |                   |         |          | enterprise IdP.  MUST   |
     |                   |         |          | NOT be the Registry's   |
     |                   |         |          | registry_id.            |
     +-------------------+---------+----------+-------------------------+
     | sub               | string  | REQUIRED | MUST be the acting      |
     |                   |         |          | agent's AID.            |
     +-------------------+---------+----------+-------------------------+
     | aud               | string  | REQUIRED | MUST be the enterprise  |
     |                   | or      |          | IdP's token endpoint    |
     |                   | array   |          | URI.                    |
     +-------------------+---------+----------+-------------------------+
     | aip_sub_principal | string  | REQUIRED | MUST be the root        |
     |                   |         |          | Principal Token         |
     |                   |         |          | principal.id value from |



  Singla                  Expires 15 November 2026               [Page 73]


  Internet-Draft                     AIP                          May 2026


     |                   |         |          | aip_chain[0] of the     |
     |                   |         |          | validated Credential    |
     |                   |         |          | Token.  MUST be a valid |
     |                   |         |          | W3C DID.                |
     +-------------------+---------+----------+-------------------------+
     | aip_scopes        | array   | REQUIRED | MUST be the validated   |
     |                   | of      |          | aip_scope values from   |
     |                   | strings |          | the Credential Token.   |
     |                   |         |          | MUST NOT include scopes |
     |                   |         |          | not present in the      |
     |                   |         |          | validated Credential    |
     |                   |         |          | Token.                  |
     +-------------------+---------+----------+-------------------------+
     | iat               | integer | REQUIRED | Unix timestamp          |
     |                   |         |          | representing the        |
     |                   |         |          | current time at         |
     |                   |         |          | assertion construction. |
     +-------------------+---------+----------+-------------------------+
     | exp               | integer | REQUIRED | Unix timestamp.  MUST   |
     |                   |         |          | be iat + 60 or earlier. |
     |                   |         |          | Registries MUST NOT     |
     |                   |         |          | issue assertions with   |
     |                   |         |          | exp - iat > 60.         |
     +-------------------+---------+----------+-------------------------+
     | jti               | string  | REQUIRED | UUID v4.  MUST be       |
     |                   |         |          | unique per assertion to |
     |                   |         |          | prevent replay.         |
     +-------------------+---------+----------+-------------------------+

                                   Table 16

  8.4.5.2.  Enterprise IdP Error Handling

     When the enterprise IdP token endpoint returns an error or cannot be
     reached, the AIP Registry MUST map the result to the agent-facing AIP
     response as follows:















  Singla                  Expires 15 November 2026               [Page 74]


  Internet-Draft                     AIP                          May 2026


       +============================+==================================+
       | Enterprise IdP Response    | AIP Registry Response to Agent   |
       +============================+==================================+
       | HTTP 400 (invalid_request) | HTTP 400, error: invalid_request |
       +----------------------------+----------------------------------+
       | HTTP 400 (invalid_client)  | HTTP 500, error:                 |
       |                            | idp_client_misconfigured         |
       +----------------------------+----------------------------------+
       | HTTP 400 (invalid_grant)   | HTTP 400, error: invalid_grant   |
       +----------------------------+----------------------------------+
       | HTTP 400                   | HTTP 403, error:                 |
       | (unauthorized_client)      | insufficient_scope               |
       +----------------------------+----------------------------------+
       | HTTP 403 (access_denied or | HTTP 403, error:                 |
       | Conditional Access denial) | enterprise_policy_denied         |
       +----------------------------+----------------------------------+
       | HTTP 4xx (other)           | HTTP 400, error: invalid_request |
       +----------------------------+----------------------------------+
       | HTTP 5xx                   | HTTP 503, error:                 |
       |                            | registry_unavailable             |
       +----------------------------+----------------------------------+
       | Timeout greater than 5     | HTTP 503, error:                 |
       | seconds                    | registry_unavailable             |
       +----------------------------+----------------------------------+
       | TLS or network error       | HTTP 503, error:                 |
       |                            | registry_unavailable             |
       +----------------------------+----------------------------------+

                                    Table 17

     The Registry MUST NOT expose raw enterprise IdP error messages to the
     calling agent.  When enterprise_policy_denied is returned, the
     error_description SHOULD indicate that the request was denied by
     enterprise policy without revealing specific policy rules.  The
     Registry MUST log the full enterprise IdP response for audit purposes
     per Section 21.4.

  8.4.5.3.  Federation Metadata and Grant Tier Guidance

     AIP Registries that support this profile MUST advertise
     enterprise_idp_federation_supported: true in their /v1/registry-
     metadata metadata as described by Section 7.4.4 and Section 17.14.1.
     Relying Parties and agents MUST NOT infer federation support from
     absence of this field.







  Singla                  Expires 15 November 2026               [Page 75]


  Internet-Draft                     AIP                          May 2026


     Enterprise deployments using this profile SHOULD require G3 grants
     from Section 12 for the root Principal Token so that human
     authentication context and IdP policy context are available during
     token exchange and Tier 3 validation.

  9.  Credential and Step Execution Token Validation

     The Credential Token Validation Algorithm is the normative heart of
     AIP for agent-issued Credential Tokens.  A Relying Party MUST execute
     the following steps in the order presented unless it is validating a
     Registry-issued Step Execution Token under the SET validation profile
     below.  Validation is deterministic: two independent implementations
     executing the same steps on the same token with the same Registry
     state MUST reach the same outcome.

     The Relying Party MUST reject the token at the first step that fails.
     Additional lettered steps marked 2a, 6a, 6b, 9a, 9b, 9c, 9d, and 10a
     are part of the numbered step at which they appear and do not change
     the base step numbering.

     The labels in the following table are normative validation step
     identifiers for implementation traceability and conformance tests.
     Lettered labels, including Steps 5a through 5g, 8a through 8l, and
     11a through 11c, are discrete sub-steps whether they appear as
     separate XML section headings or as labelled items within a
     validation step.

            +============+=============+==========================+
            | Label      | Location    | Validation subject       |
            +============+=============+==========================+
            | 1          | Section 9.1 | JWT parse                |
            +------------+-------------+--------------------------+
            | 2          | Section 9.2 | JWT header validation    |
            +------------+-------------+--------------------------+
            | 2a         | Section 9.3 | Expiration preflight     |
            |            |             | before Registry lookup   |
            +------------+-------------+--------------------------+
            | 3          | Section 9.4 | Agent identification and |
            |            |             | public-key retrieval     |
            +------------+-------------+--------------------------+
            | 4          | Section 9.5 | Credential Token         |
            |            |             | signature verification   |
            +------------+-------------+--------------------------+
            | 5a         | Section     | iat issued-at validation |
            |            | 9.6.1       |                          |
            +------------+-------------+--------------------------+
            | 5b         | Section     | exp ordering validation  |
            |            | 9.6.2       |                          |



  Singla                  Expires 15 November 2026               [Page 76]


  Internet-Draft                     AIP                          May 2026


            +------------+-------------+--------------------------+
            | 5c         | Section     | Credential Token         |
            |            | 9.6.3       | expiration validation    |
            +------------+-------------+--------------------------+
            | 5d         | Section     | aud validation           |
            |            | 9.6.4       |                          |
            +------------+-------------+--------------------------+
            | 5e         | Section     | jti replay validation    |
            |            | 9.6.5       |                          |
            +------------+-------------+--------------------------+
            | 5f         | Section     | aip_version validation   |
            |            | 9.6.6       |                          |
            +------------+-------------+--------------------------+
            | 5g         | Section     | Issuer and subject       |
            |            | 9.6.7       | binding                  |
            +------------+-------------+--------------------------+
            | 6          | Section 9.7 | Credential Token TTL     |
            |            |             | validation               |
            +------------+-------------+--------------------------+
            | 6a         | Section 9.8 | Registry trust anchoring |
            +------------+-------------+--------------------------+
            | 6b         | Section 9.9 | Engagement validation    |
            +------------+-------------+--------------------------+
            | 7          | Section     | Revocation validation    |
            |            | 9.10        |                          |
            +------------+-------------+--------------------------+
            | 8a-8l      | Section     | Delegation chain sub-    |
            |            | 9.11        | step validation          |
            +------------+-------------+--------------------------+
            | 8 Post-    | Section     | Credential Token issuer  |
            | Check A    | 9.11        | equals chain leaf        |
            +------------+-------------+--------------------------+
            | 8 Post-    | Section     | Credential Token subject |
            | Check B    | 9.11        | equals issuer            |
            +------------+-------------+--------------------------+
            | 8 Post-    | Section     | Identity proofing claims |
            | Check C    | 9.11        |                          |
            +------------+-------------+--------------------------+
            | 9          | Section     | Capability Manifest      |
            |            | 9.12        | validation               |
            +------------+-------------+--------------------------+
            | 9a         | Section     | Scope-to-manifest        |
            |            | 9.13        | mapping                  |
            +------------+-------------+--------------------------+
            | 9b         | Section     | Capability Overlay       |
            |            | 9.14        | application              |
            +------------+-------------+--------------------------+
            | 9c         | Section     | Delegation inheritance   |



  Singla                  Expires 15 November 2026               [Page 77]


  Internet-Draft                     AIP                          May 2026


            |            | 9.15        |                          |
            +------------+-------------+--------------------------+
            | 9d         | Section     | Grant Tier conformance   |
            |            | 9.16        |                          |
            +------------+-------------+--------------------------+
            | 10         | Section     | DPoP validation          |
            |            | 9.17        |                          |
            +------------+-------------+--------------------------+
            | 10a        | Section     | Approval step            |
            |            | 9.18        | verification             |
            +------------+-------------+--------------------------+
            | 11a        | Section     | aip_principal_assertion  |
            |            | 9.19        | presence                 |
            +------------+-------------+--------------------------+
            | 11b        | Section     | aip_principal_assertion  |
            |            | 9.19        | signature verification   |
            +------------+-------------+--------------------------+
            | 11c        | Section     | aip_principal_assertion  |
            |            | 9.19        | principal binding        |
            +------------+-------------+--------------------------+
            | 12         | Section     | Accept                   |
            |            | 9.20        |                          |
            +------------+-------------+--------------------------+

                Table 18: Credential Token Validation Step Index

  9.1.  Step 1: Parse

     Parse the Authorization header value as a JWT per [RFC7519].  If
     parsing fails or the token is malformed, reject with invalid_token.

  9.2.  Step 2: Header Validation

     Verify the JWT header contains:

     *  typ: MUST be "AIP+JWT"

     *  alg: MUST be "EdDSA"

     *  kid: MUST be present and MUST be a DID URL in the form
        did:aip:<namespace>:<32-hex>#key-<n>

     If any check fails, reject with invalid_token.








  Singla                  Expires 15 November 2026               [Page 78]


  Internet-Draft                     AIP                          May 2026


  9.3.  Step 2a: Expiration Preflight

     Before performing any Registry key lookup, the Relying Party MUST
     decode the JWT payload without using it for any acceptance decision.
     This preflight is only an error-ordering and lookup-amplification
     control.  Signature verification in Step 4 and full claim validation
     in Step 5 remain mandatory before a token can be accepted.

     The Relying Party MUST inspect only iat, exp, and aip_scope during
     this preflight.  If iat or exp is absent, not an integer, or exp <=
     iat, reject with invalid_token.  If exp is in the past, reject with
     token_expired.  This rejection applies even if the token's kid
     references a historical key version that is no longer retained by the
     Registry.

     If the unsigned payload's exp - iat exceeds the largest
     ttl_max_seconds value among active entries in the synced AIP Scope
     Catalog, the Relying Party MAY reject with invalid_token before key
     lookup.  This check is conservative: it can reject tokens that no
     valid catalog entry could authorize, but it MUST NOT be used to
     accept a token.

  9.4.  Step 3: Identify Agent and Retrieve Public Key

     Extract the kid header parameter.  This is a full DID URL identifying
     the agent's public key.  Contact the Registry to retrieve the
     historical public key matching this kid using GET /v1/
     agents/{aid}/public-key/{key-id}, where {aid} is the DID URL without
     the fragment and {key-id} is the fragment without the leading #.  The
     Registry response MUST conform to public-key-response.schema.json and
     return the public key material along with its validity period
     (valid_from timestamp and valid_until timestamp or null).

     If the Registry cannot be reached or the public key lookup cannot be
     completed because the Registry is unavailable, reject with
     registry_unavailable.  If the Registry lookup succeeds but the kid is
     not found or the key is not valid at the time of the JWT's iat claim,
     reject with unknown_aid.  Because Step 2a runs before this lookup, an
     already-expired token MUST surface as token_expired, not unknown_aid,
     even when its historical signing key has aged out of Registry
     retention.

  9.5.  Step 4: Verify Signature

     Verify the JWT signature using the public key retrieved in Step 3.
     The signature verification MUST use constant-time comparison.  If
     signature verification fails, reject with invalid_token.




  Singla                  Expires 15 November 2026               [Page 79]


  Internet-Draft                     AIP                          May 2026


  9.6.  Step 5: Validate Claims

     Validate the following claims from the decoded JWT payload:

  9.6.1.  Step 5a: iat (Issued-At Time)

     iat MUST NOT be in the future.  Allow a 30-second clock skew
     tolerance.  If iat is in the future (beyond skew), reject with
     invalid_token.

  9.6.2.  Step 5b: exp (Expiration Time)

     exp MUST be strictly greater than iat (zero-duration tokens are not
     permitted).  If exp <= iat, reject with invalid_token.

  9.6.3.  Step 5c: Token Not Expired

     exp MUST be in the future (current time must be < exp).  If exp is in
     the past, reject with token_expired.

  9.6.4.  Step 5d: aud (Audience)

     The aud claim MUST match the Relying Party's identifier.  If aud is a
     string, it MUST match exactly.  If aud is an array, the Relying
     Party's identifier MUST be present in the array.  If no match, reject
     with invalid_token.

  9.6.5.  Step 5e: jti (JWT ID) Replay Check

     jti MUST be a UUID v4 in canonical form (lowercase, hyphenated).  The
     Relying Party MUST maintain a replay cache keyed by (iss, jti) for
     each token's validity window.  If (iss, jti) has been seen before,
     reject with token_replayed.  This replay rule applies to
     authorisation decisions.  Registry state-transition endpoints that
     define explicit idempotency behavior MAY return a previously stored
     response for an exact retry, but MUST NOT re-execute side effects and
     MUST NOT treat replay-cache acceptance as proof of fresh authority.
     The replay cache key MUST NOT include aip_chain, principal DID,
     registration grant, scope set, or audience.  Credential Token issuers
     therefore MUST treat jti values as globally unique within the issuer
     AID across all delegation chains.  After the token expires, the
     replay cache entry MAY be discarded.









  Singla                  Expires 15 November 2026               [Page 80]


  Internet-Draft                     AIP                          May 2026


  9.6.6.  Step 5f: aip_version

     aip_version MUST be present and MUST be "0.3" for tokens conforming
     to this specification.  This value is the AIP protocol compatibility
     version defined in Section 20, not the Internet-Draft revision
     suffix.  If aip_version is absent, reject with invalid_token.  If
     aip_version is present but unsupported, or if it does not match the
     X-AIP-Version request header, reject with unsupported_version and
     include the received aip_version and X-AIP-Version values in the
     error description to aid debugging.

  9.6.7.  Step 5g: Issuer and Subject Binding

     The iss and sub claims MUST each match the did:aip ABNF.  Let kid_aid
     be the DID URL in the JWT header kid with the fragment removed.  The
     payload iss MUST equal kid_aid.  The payload sub MUST equal iss.
     This specification does not define agent-issued Credential Tokens
     where a delegated token subject differs from the signing leaf agent.
     If any comparison fails, reject with invalid_token.

  9.7.  Step 6: TTL Validation

     Verify that the token's lifetime does not exceed the maximum
     permitted by its scopes.  Compute lifetime = exp - iat (in seconds).
     Compare against the ttl_max_seconds values in the synced AIP Scope
     Catalog and the Tier ceilings in Section 8.2:

     effective_ttl_limit =
       min(
         scope.ttl_max_seconds,
         tier_ttl_ceiling(scope.tier)
         for scope in aip_scope
       )

     When a token contains multiple scopes, the most
     restrictive catalog TTL applies.

     If lifetime exceeds the limit, reject with invalid_token.

     For validation, a token's security Tier is determined by its highest-
     risk scope (Section 3.2).  A token containing one Tier 2 scope and
     nine Tier 1 scopes is a Tier 2 token in its entirety.  A Relying
     Party MUST NOT derive Tier from the majority of scopes or from the
     first scope in the array.







  Singla                  Expires 15 November 2026               [Page 81]


  Internet-Draft                     AIP                          May 2026


  9.8.  Step 6a: Registry Trust Anchoring (Conditional)

     This step is REQUIRED for Tier 2 and Tier 3 operations and for any
     Credential Token that contains aip_registry.  It is RECOMMENDED for
     Tier 1 operations when aip_registry is absent.  It verifies that the
     Registry from which the Relying Party has been fetching data matches
     the Registry declared by the principal's DID Document.

     1.  Extract principal_id from aip_chain[0].iss (the root principal's
         DID).  This is the authorising human or organisational principal.

     2.  If the operation's security Tier is 2 or 3, principal_id MUST use
         the did:web method.  If it uses did:key, did:aip, or any other
         DID method, reject with principal_did_method_forbidden.

     3.  Resolve principal_id using the DID method's own resolution
         mechanism (e.g., did:web resolution per [W3C-DID], did:key per
         [W3C-DID]).  The resolution MUST be independent of any agent-
         provided data.  Use the DID method's canonical resolver.

     4.  Examine the resolved DID Document's service array.  Locate an
         entry with type: "AIPRegistry".

     5.  Extract the serviceEndpoint URI from that service entry.  This is
         the authoritative Registry URI for this principal.

     6.  Verify that the Registry from which the Relying Party has been
         fetching revocation status, Capability Manifests, and step data
         matches the declared serviceEndpoint URI.  Perform origin
         comparison per [RFC6454] (scheme + host + port must match).

     7.  If aip_registry is present in the Credential Token, verify it
         matches the DID-Document-declared Registry endpoint.  If
         mismatch, reject with registry_untrusted.

     8.  If the DID Document does not contain an AIPRegistry service entry
         and the operation's security Tier is 2 or 3 or the token contains
         aip_registry, reject with registry_untrusted.

     For Tier 1 operations where aip_registry is absent, this step is
     RECOMMENDED.  Registry trust anchoring prevents MitM Registry
     substitution but adds latency (additional DID resolution).  Tier 1
     operators MAY skip this step if they accept the risk that the
     Registry might be MitM'd with a loss of up to 15-minute revocation
     staleness.

     If DID resolution fails and the operation's security Tier is 2 or 3
     or the token contains aip_registry, reject with registry_unavailable.



  Singla                  Expires 15 November 2026               [Page 82]


  Internet-Draft                     AIP                          May 2026


     DID resolution for this step MUST use the timeout requirements in
     Section 7.1.  For Tier 2 or Tier 3 operations and tokens containing
     aip_registry, a DID resolution timeout is a validation failure and
     MUST be reported as registry_unavailable; implementations MUST NOT
     wait indefinitely for the principal DID resolver.

     A Relying Party MUST NOT use aip_registry as an authoritative
     Registry locator unless this step has verified it against the DID-
     Document-declared Registry endpoint.

  9.9.  Step 6b: Engagement Validation (Conditional)

     This step applies only if aip_engagement_id is present in the
     Credential Token payload.

     1.  Fetch the Engagement Object from the Registry via GET /v1/
         engagements/{aip_engagement_id}.

     2.  Verify the Engagement's status field.  If "active", continue.  If
         "completed" or "terminated", reject with engagement_terminated.
         If "suspended", reject with engagement_suspended.

     3.  Verify that the token's sub (agent AID) appears in the
         Engagement's participants array as an active participant.  If sub
         is not in the participants array or has been marked as removed,
         reject with engagement_participant_removed.

     4.  If the Engagement defines approval_gates with pending gates that
         guard the current operation, evaluate each gate trigger using the
         trigger grammar in Section 5.12.  A scope:<scope-string> trigger
         guards any operation whose requested aip_scope set contains that
         scope.  An action_type:<action-type> trigger guards Approval
         Envelope steps whose action_type exactly equals that value.  If a
         matching required gate is still pending, reject with
         engagement_gate_pending.  If a matching required gate has status
         "rejected", reject with engagement_terminated.

  9.10.  Step 7: Revocation Check

     Query the Registry for revocation status of the agent identified by
     iss (extracted from the kid).  The revocation check method depends on
     the token's Tier.  Chain-wide and principal-wide revocation effects
     are completed in Step 8 after aip_chain has been validated.

     *  *Tier 1:* Retrieve a verifiable CRL from the Registry cache.  The
        CRL's next_update MUST be later than the Relying Party's current
        UTC validation time.  If no fresh verifiable CRL is available,
        reject with registry_unavailable.  If the agent appears on the CRL



  Singla                  Expires 15 November 2026               [Page 83]


  Internet-Draft                     AIP                          May 2026


        with revocation type full_revoke or principal_revoke, reject with
        agent_revoked.  If the agent appears with scope_revoke, the
        Relying Party MUST verify that none of the scopes in the token's
        aip_scope are present in the scopes_revoked list.  If any match,
        reject with agent_revoked.  The same CRL MUST also be used in Step
        8 to evaluate principal_revoke entries whose target_id is the root
        Principal DID or any AID in the validated aip_chain.

     *  *Tier 2:* Perform a live Registry lookup.  Query GET /v1/
        agents/{iss}/revocation.  A successful response MUST be HTTP 200
        with a body conforming to revocation-status.schema.json
        (Section 17.8).  If revoked is true, reject with agent_revoked.
        If any currently requested scope appears in scopes_revoked, reject
        with agent_revoked.  If the token relies on delegation authority
        rooted at an AID whose response has delegation_revoked equal to
        true, reject with agent_revoked.  If the Registry returns
        unknown_aid, reject with unknown_aid.  If the Registry is
        unreachable, reject with registry_unavailable.  A previously
        cached accepted token validation result MUST NOT be used to skip
        this lookup.

     The Relying Party MUST verify the Registry trust state used for this
     revocation check using the Registry trust bootstrapping and Registry
     Trust Record procedures in Section 7.4.4 and Section 7.4.5, and the
     sequential trust-update procedure in Section 7.4.7.1 when updating
     pinned trust state, before treating Registry responses as
     authoritative.

  9.11.  Step 8: Delegation Chain Validation

     Validate the Principal Token delegation chain in aip_chain.  This
     array contains one or more compact-serialised JWTs, each conforming
     to the Principal Token schema.

     For each Principal Token at index i (from 0 to n-1 where n is the
     length of aip_chain):

     8a.  Valid JWT:  The token at index i MUST be a valid, well-formed
        JWT conforming to the Principal Token schema.  Its JOSE header
        MUST contain typ equal to "JWT", alg equal to "EdDSA", and a non-
        empty kid DID URL.  If parsing, schema validation, or header
        validation fails, reject with delegation_chain_invalid.

     8b. delegation_depth Matches Index:  The delegation_depth claim in
        token i MUST equal exactly i.  The array is 0-indexed:
        aip_chain[0] has delegation_depth: 0, and aip_chain[1], when
        present, has delegation_depth: 1.  If mismatch, reject with
        invalid_delegation_depth.



  Singla                  Expires 15 November 2026               [Page 84]


  Internet-Draft                     AIP                          May 2026


     8c.  Delegation Depth Does Not Exceed Maximum:  The delegation_depth
        of token i MUST NOT exceed the max_delegation_depth value declared
        in token 0 (the root token).  If max_delegation_depth is absent
        from token 0, the default is 3.  If i exceeds this limit, reject
        with invalid_delegation_depth.

     8d.  Issuer and kid Binding:  For token at index i, extract the iss
        claim.  For i = 0, iss MUST equal principal.id.  For i > 0, iss
        MUST equal delegated_by.  The kid header MUST identify an Ed25519
        verification method controlled by iss, and the DID portion of kid
        MUST equal iss.  If any of these bindings fail, reject with
        delegation_chain_invalid.

     8d-1.  Root Principal Signature Verification:  For i = 0, resolve kid
        using the DID method of the root principal DID in principal.id.
        The AIP Registry MUST NOT be used as the authority for root-
        principal keys.  If DID resolution fails, the key is not Ed25519
        verification material, the verification method is not controlled
        by principal.id, or signature verification fails, reject with
        delegation_chain_invalid.

     8d-2.  Delegated Agent Key Lookup:  For i > 0, iss is the parent
        agent AID that signed this delegated Principal Token.  The Relying
        Party MUST resolve the signing key through the authoritative AIP
        Registry using the percent-encoded issuer AID and the kid
        fragment: GET /v1/agents/{iss}/public-key/{key-id}. The key-id
        path component is the fragment portion of kid without the leading
        number-sign character.  The Registry response MUST identify the
        same AID as iss and return Ed25519 public key material whose
        validity interval covers the Principal Token's issued_at instant.
        If the Registry cannot be reached or the key lookup cannot be
        completed because the Registry is unavailable, reject with
        registry_unavailable.  If the Registry lookup succeeds but iss is
        not a registered AID, kid is not found, or the key is not valid at
        issued_at, reject with unknown_aid.

     8d-3.  Delegated Principal Token Signature Verification:  For i > 0,
        verify the Principal Token signature using the key resolved in
        Step 8d-2.  If the resolved key is not Ed25519 verification
        material, identifies a key not controlled by iss, or signature
        verification fails, reject with delegation_chain_invalid.

     8e.  Delegation Chain Linkage:  For token at index i > 0, verify that








  Singla                  Expires 15 November 2026               [Page 85]


  Internet-Draft                     AIP                          May 2026


        delegated_by[i] equals sub[i-1] (the sub of the previous token).
        This ensures the chain is continuous: each agent is delegated by
        the previous agent in the chain.  A delegated Principal Token MUST
        NOT be self-delegated: delegated_by[i] MUST NOT equal sub[i].  If
        linkage fails or the token is self-delegated, reject with
        delegation_chain_invalid.

     8f.  Agent Revocation:  For each sub AID in the chain (at all
        indices), verify it is not revoked using the same Tier-specific
        revocation check as Step 7.  If the Registry returns unknown_aid
        for any chain sub AID, reject with unknown_aid.  If any agent in
        the chain is revoked, reject with agent_revoked.  A
        principal_revoke whose target_id equals any chain sub AID MUST be
        treated as revoked even when no descendant Revocation Object has
        been materialised for that AID.

     8g.  No Duplicate AIDs:  No AID may appear more than once in the
        chain (no cycles or duplicates).  This rule includes direct self-
        delegation, where a Principal Token attempts to delegate from an
        AID back to the same AID.  If an AID appears at indices i and j
        with i != j, reject with delegation_chain_invalid.

     8h.  Token Validity:  For token at index i, parse issued_at and
        expires_at as ISO 8601 UTC instants.  Verify issued_at is not more
        than 30 seconds in the future relative to the Relying Party's
        current UTC clock.  If it is, reject with
        delegation_chain_invalid.  Verify expires_at > issued_at; if not,
        reject with delegation_chain_invalid.  Verify expires_at is in the
        future; if expired, reject with chain_token_expired.

     8i.  Consistent Principal:  The principal.id field MUST be byte-for-
        byte identical across ALL elements in the chain (index 0 through
        n-1).  This ensures the chain always traces to the same root
        principal.  If any element has a different principal.id, reject
        with delegation_chain_invalid.

     8j.  Principal is Not an Agent:  The principal.id from aip_chain[0]
        MUST NOT begin with did:aip:. Principals are humans or
        organisations, never agents.  If principal.id uses the did:aip
        method, reject with delegation_chain_invalid.

     8k.  Namespace Task Binding:  For every Principal Token whose sub
        namespace has requires_task_id: true in the synced AIP Namespace
        Catalog, the token payload MUST include a non-null, non-empty
        task_id.  If such a chain element omits task_id, sets it to null,
        or sets it to an empty string, reject with
        delegation_chain_invalid.




  Singla                  Expires 15 November 2026               [Page 86]


  Internet-Draft                     AIP                          May 2026


     8l.  Root Principal Revocation:  Let root_principal_id be the
        principal.id value that Step 8i verified across the chain.  Using
        the revocation source required for the token's Tier, verify that
        no active principal_revoke has target_id equal to
        root_principal_id.  A match invalidates every Credential Token and
        Step Execution Token rooted at that Principal DID; reject with
        agent_revoked.  This rejection is required regardless of the
        propagate_to_children value on the Revocation Object.

  9.11.1.  Step 8 Post-Check A

     After validating all elements in the chain, verify that iss (the
     issuer of the Credential Token, from the JWT header kid) MUST equal
     aip_chain[n-1].sub (the sub of the last element in the chain, i.e.,
     the acting agent's AID).  This confirms that the agent issuing the
     token is the leaf of the delegation chain.  If mismatch, reject with
     delegation_chain_invalid.

  9.11.2.  Step 8 Post-Check B

     Verify that the Credential Token payload sub MUST equal iss.
     Together with Post-Check A, this confirms that the token subject,
     token issuer, signing key AID, and leaf Principal Token subject all
     identify the same acting agent.  This check applies to both direct
     and delegated Credential Tokens.  If mismatch, reject with
     delegation_chain_invalid.

  9.11.3.  Step 8 Post-Check C: Identity Proofing

     This check applies when any scope in aip_scope has synced AIP Scope
     Catalog tier 3, when the Registry's
     identity_proofing_required_for_tier2 metadata field is true and the
     operation security Tier is 2, when Registry registration metadata for
     the agent identifies grant_tier: "G3", or when the Relying Party or
     operation policy declares one or more required acr_values.

     When this check applies, the root Principal Token at aip_chain[0]
     MUST include a non-empty acr string and a non-empty amr array.  If
     either claim is absent or empty, the Relying Party MUST reject the
     request with identity_proofing_insufficient.

     The Relying Party MUST evaluate only the acr and amr values contained
     in the signed root Principal Token.  It MUST NOT accept unsigned or
     out-of-band acr or amr values for this check.

     If one or more acr_values are required, the acr value in aip_chain[0]
     MUST exactly match one of those required values unless the Registry's
     /v1/registry-metadata document contains an acr_equivalence_map object



  Singla                  Expires 15 November 2026               [Page 87]


  Internet-Draft                     AIP                          May 2026


     (Section 17.14.1) that explicitly maps the received acr value to one
     of the required values.  Equivalence MUST only map a received value
     to a declared required value where the received value represents
     equal or higher assurance than the required value under the
     Registry's published ACR equivalence policy.  The acr_equivalence_map
     MUST NOT map a lower-assurance acr to a higher-assurance acr.  The
     policy MUST identify the assurance framework or frameworks used for
     each mapping and MUST give a stable ordering or rationale sufficient
     for an auditor to reproduce the decision.  Implementations MUST NOT
     accept equivalence mappings from any source other than the Registry's
     signed /v1/registry-metadata document and its referenced policy.
     This specification does not define a global ordering over acr values.
     If the acr claim does not satisfy the declared requirement, the
     Relying Party MUST reject the request with
     identity_proofing_insufficient.

  9.12.  Step 9: Capability Validation

     Verify that the agent's requested scopes are permitted by its
     Capability Manifest.

     1.  Fetch the Capability Manifest for the agent identified by iss
         from GET /v1/agents/{iss}/capabilities.  The response MUST
         conform to capability-manifest.schema.json, and manifest.aid MUST
         equal iss.  If unavailable, malformed, or not bound to iss,
         reject with manifest_invalid.

     2.  Verify the manifest signature using manifest.signature_kid.  The
         DID portion of signature_kid MUST equal manifest.granted_by.  If
         key resolution, key binding, or signature verification fails,
         reject with manifest_invalid.

     3.  Verify expires_at is in the future.  If expired, reject with
         manifest_expired.

     4.  For each requested scope whose synced AIP Scope Catalog entry has
         a non-null constraint_schema, validate the corresponding
         Capability Manifest value against that schema.  If validation
         fails, reject with manifest_invalid.

  9.13.  Step 9a: Scope Verification

     For all agents: verify each scope in aip_scope is present with
     status: "active" or, when local policy allows experimental behavior,
     status: "experimental" in the synced AIP Scope Catalog.  If any
     requested scope is unknown, reserved, removed, or not permitted by
     local extension policy, reject with invalid_scope.  Then verify each
     requested scope is present in the Capability Manifest.  If any



  Singla                  Expires 15 November 2026               [Page 88]


  Internet-Draft                     AIP                          May 2026


     requested scope is absent from the Capability Manifest, reject with
     insufficient_scope.

  9.14.  Step 9b: Capability Overlay (Conditional)

     If a Capability Overlay exists, verify scope constraints permit the
     requested operation.  For each overlay constraint whose synced AIP
     Scope Catalog entry has a non-null constraint_schema, validate the
     overlay constraint against that schema before applying attenuation.
     If schema validation fails, reject with overlay_exceeds_manifest.

  9.15.  Step 9c: Delegation Scope Inheritance

     For delegated Credential Tokens, the Relying Party MUST verify that
     the requested scopes and the leaf agent's Capability Manifest are
     valid attenuations of every delegation in aip_chain.

     Let chain[i] be the decoded Principal Token payload at aip_chain[i],
     and let manifest(chain[i].sub) be the current Capability Manifest for
     the agent identified by chain[i].sub.  Let n be the length of
     aip_chain.  The Relying Party MUST execute the inheritance validation
     in increasing index order, from the root delegated agent (i = 0) to
     the leaf acting agent (i = n-1).

     1.  For every i from 0 to n-1, obtain the current Capability Manifest
         M[i] for chain[i].sub.  The leaf manifest M[n-1] MAY reuse the
         manifest already fetched in Step 9.  All ancestor manifests MUST
         be fetched according to the caching rules in Section 10.  If any
         required manifest is unavailable, reject with manifest_invalid.

     2.  For every obtained manifest M[i], verify M[i].aid ==
         chain[i].sub, verify the manifest signature using
         M[i].signature_kid, verify the DID portion of M[i].signature_kid
         equals M[i].granted_by, and verify that M[i].expires_at is in the
         future.  If the AID binding, key binding, or signature check
         fails, reject with manifest_invalid.  If the manifest is expired,
         reject with manifest_expired.

     3.  For every requested scope in aip_scope, verify that the scope is
         present in the scope array of every Principal Token in aip_chain
         and is granted by the leaf manifest M[n-1].  If any requested
         scope is absent from any chain token or from the leaf manifest,
         reject with insufficient_scope.

     4.  For every adjacent pair (M[i-1], M[i]) where i ranges from 1 to
         n-1, verify that the child manifest M[i] is a valid attenuation
         of the parent manifest M[i-1].  Every scope granted by M[i] MUST
         be present in M[i-1], and every child constraint for that scope



  Singla                  Expires 15 November 2026               [Page 89]


  Internet-Draft                     AIP                          May 2026


         MUST be equal to or more restrictive than the corresponding
         parent constraint.  If a child scope is absent from the parent
         manifest, or if a child constraint is more permissive than the
         parent constraint, reject with insufficient_scope.

     Constraint comparison MUST use the recursive attenuation semantics
     from Rule CO-1, treating the parent manifest constraint as the base
     value and the child manifest constraint as the overlay value.  When
     the synced AIP Scope Catalog provides a non-null constraint_schema,
     both parent and child constraints MUST first validate against that
     schema.  If schema validation fails, reject with manifest_invalid.
     Any violation at any adjacent pair is fatal to the chain.  For
     example, a chain where M[0].transactions.max_single_transaction =
     250, M[1].transactions.max_single_transaction = 300, and
     M[2].transactions.max_single_transaction = 200 is invalid at pair
     (M[0], M[1]), even though M[2] is more restrictive than M[1].

  9.16.  Step 9d: Grant Tier Conformance

     Determine the operation's security Tier as the highest tier value
     among all requested aip_scope entries in the synced AIP Scope
     Catalog.  For every Principal Token payload in aip_chain, retrieve
     the registered grant_tier from the Registry registration metadata for
     the AID identified by that payload's sub.  The Relying Party MUST
     reject the request with grant_tier_insufficient if any participating
     AID's registered grant_tier is absent, unrecognised, or not permitted
     for the operation's security Tier.

     The permitted runtime mappings are: Tier 1 permits G1, G2, or G3;
     Tier 2 permits G2 or G3; Tier 3 permits only G3.  For Tier 2 and Tier
     3, the root principal DID MUST use the did:web method.  A higher-
     assurance Grant Tier MAY satisfy a lower security Tier, but a lower-
     assurance Grant Tier MUST NOT satisfy a higher security Tier.

     If the operation's security Tier is 2 and the Registry's
     identity_proofing_required_for_tier2 metadata field is true, Tier 2
     permits only G3 for this Registry.  In that case, a participating AID
     registered with G2 MUST be rejected with grant_tier_insufficient.

  9.17.  Step 10: DPoP Validation (Conditional)

     For this step, the operation's security Tier is the highest Tier
     among all requested scopes.  A token containing one Tier 2 scope is a
     Tier 2 token for DPoP validation.

     DPoP (Demonstration of Proof-of-Possession) MUST be verified when the
     operation's security Tier is 2 or 3, when any requested scope has
     requires_dpop: true in the synced AIP Scope Catalog, or when the



  Singla                  Expires 15 November 2026               [Page 90]


  Internet-Draft                     AIP                          May 2026


     requested Registry endpoint requires DPoP independently of scope
     metadata.  A Tier 2 or Tier 3 operation requires DPoP even if every
     requested scope has requires_dpop: false.

     If DPoP is required, the HTTP request MUST include a DPoP header
     containing a Demonstration of Proof-of-Possession proof JWT per
     [RFC9449].  Verify:

     1.  The DPoP proof is a valid JWT.

     2.  The htm (HTTP method) claim matches the HTTP method of the
         request.

     3.  The htu (HTTP URI) claim matches the absolute target URI of the
         current request after removing query and fragment components,
         with URI normalization performed as specified for DPoP in
         [RFC9449].  Because htu includes the target origin and path, a
         DPoP proof captured at one Relying Party or Registry MUST NOT
         validate at another Relying Party or Registry unless the
         normalized target URI is identical.

     4.  The ath claim is present and equals BASE64URL(SHA-256(token)),
         where token is the exact compact Credential Token or Step
         Execution Token value from the Authorization header after
         removing the authorization scheme and surrounding whitespace.
         When DPoP is required, the authorization scheme MUST be DPoP.
         The hash input MUST NOT include the authorization scheme,
         whitespace, or the DPoP proof itself.

     5.  The iat claim is within the verifier's accepted DPoP proof
         window.  Unless the verifier requires a server-provided DPoP
         nonce per [RFC9449], the verifier MUST reject proofs whose iat is
         more than 300 seconds before receipt time or more than 30 seconds
         after receipt time.  When a server-provided nonce is required,
         the verifier MUST validate the nonce claim and the server-managed
         nonce lifetime instead of extending acceptance based on a client-
         chosen future iat.

     6.  The jti has not been seen before (DPoP-specific replay cache,
         separate from Credential Token jti cache, keyed by (kid, jti)).
         The replay cache is local to the verifier and MUST retain entries
         for at least the accepted DPoP proof window, or for the server-
         provided nonce lifetime when nonce validation is used, whichever
         is longer.  AIP does not require cross-Relying Party or cross-
         Registry synchronization of DPoP replay caches; cross-target
         replay prevention relies on the mandatory htm, htu, and ath
         checks above.




  Singla                  Expires 15 November 2026               [Page 91]


  Internet-Draft                     AIP                          May 2026


     7.  The public key in the jwk claim matches the effective actor's key
         material.  For an agent-issued Credential Token, this is the
         agent key that signed the Credential Token.  For a Step Execution
         Token, this is public key material controlled by the actor AID in
         sub; it is not the Registry step-execution key that signed the
         SET.

     If DPoP validation fails at any step, reject with dpop_proof_required
     (if proof is missing) or invalid_token (if proof is malformed or
     invalid).

  9.18.  Step 10a: Approval Envelope Step Verification (Conditional)

     This step applies only to Step Execution Tokens that have already
     passed the SET validation profile defined in this section.  Agent-
     issued Credential Tokens MUST NOT be accepted for Approval Envelope
     step execution merely because they contain approval-related claims.

     The Relying Party MUST call the SET issuer Registry endpoint
     identified by aip_step_kind.  For aip_step_kind: "forward", call GET
     /v1/approvals/{aip_approval_id}/steps/{n} where {n} is the value of
     aip_approval_step verbatim.  For aip_step_kind: "compensation", call
     GET /v1/approvals/{aip_approval_id}/compensation-steps/{n} where {n}
     is the value of aip_compensation_step verbatim.  In either case the
     index is an integer >= 1 and MUST NOT be decremented or adjusted.
     Both aip_approval_step and aip_compensation_step use 1-based
     indexing; the first forward step in an envelope is step 1.  This is a
     change from deprecated 0-indexed drafts.  Verify:

     1.  *Cancellation Status:* If the Registry response indicates the
         Approval Envelope or referenced step has status "cancelled",
         reject with engagement_cancelled.

     2.  *Step Status:* The step's status field MUST be "claimed".  If
         status is "pending", the step has not been claimed and cannot
         execute; reject with approval_step_not_claimed.  If status is
         "completed", "failed", "compensated", "skipped", or "cancelled",
         reject with approval_step_invalid.  Prerequisite failures are
         reported at claim time by the Registry using
         approval_step_prerequisites_unmet; a Relying Party that sees an
         unclaimed step during Step Execution Token verification treats it
         as a state conflict rather than an authorization denial.

     3.  *Actor Match:* The returned forward or compensation step's actor
         field MUST equal the Step Execution Token's sub (the actor AID).
         Reject if mismatch with approval_step_invalid.





  Singla                  Expires 15 November 2026               [Page 92]


  Internet-Draft                     AIP                          May 2026


     4.  *Relying Party Match:* The returned step's relying_party_uri MUST
         match the host of the current HTTP request (origin comparison per
         [RFC6454]: scheme + host + port).  Reject if mismatch with
         approval_step_invalid.

     5.  *Action Hash:* Compute the expected action hash for this step per
         Section 13.7.  Compare against the returned step's action_hash
         field.  If mismatch, reject with approval_step_action_mismatch.
         This ensures the approving principal authorised the exact action
         being executed.

     6.  *Scope Match:* The Step Execution Token aip_scope set MUST be
         identical to the returned step's scopes set.  Order is not
         significant for this comparison, but duplicate scope strings are
         invalid under the SET schema.  If the sets differ, reject with
         approval_step_invalid.

  9.19.  Step 11: Tier 3 Enterprise Checks (Conditional)

     This step applies only to Tier 3 enterprise deployments, which are
     declared and documented in the Registry's /v1/registry-metadata
     endpoint.

     For Tier 3 operations:

     1.  *mTLS Client Certificate:* The HTTP connection MUST use mutual
         TLS.  Validate the client certificate using the Tier 3 mTLS
         Certificate Profile in Section 21.6.  The effective actor AID is
         the Credential Token iss for agent-issued Credential Tokens, or
         the Step Execution Token sub for SETs.  If the client certificate
         is absent, reject with mtls_required.  If certificate path
         validation, key usage, EKU, SAN uniqueness, or SAN-to-actor
         matching fails, reject with invalid_token.

     2.  *OCSP Revocation Check:* Perform an OCSP check per [RFC6960] on
         the client certificate to verify it has not been revoked at the
         transport layer, or perform the equivalent deployment-profile
         revocation check allowed by Section 21.6.  If the certificate is
         revoked, reject with agent_revoked.  If revocation status is
         unavailable, stale, or indeterminate, reject with invalid_token.

     Step 11a.  Principal Assertion Presence Check:  For Tier 3 agent-
        issued Credential Tokens, the Credential Token MUST contain an
        aip_principal_assertion claim.  Absence MUST result in rejection
        with enterprise_assertion_missing.

     Step 11b.  Principal Assertion Signature Verification:  The Relying




  Singla                  Expires 15 November 2026               [Page 93]


  Internet-Draft                     AIP                          May 2026


        Party MUST resolve the iss claim of the aip_principal_assertion
        JWT to an OIDC provider configuration document and retrieve the
        provider's JWKS.  The assertion signature MUST be verified against
        the matching kid in the JWKS.  Failure MUST result in rejection
        with enterprise_assertion_invalid.

     Step 11c.  Principal Binding Check:  The sub claim of the verified
        aip_principal_assertion MUST match the root Principal Token's
        principal.id value in aip_chain[0].  A mismatch indicates that the
        agent is presenting human context that does not match its
        registered delegation chain and MUST result in rejection with
        enterprise_assertion_principal_mismatch.

     If any Tier 3 check fails, reject with the appropriate error code
     (mtls_required, invalid_token, agent_revoked,
     enterprise_assertion_missing, enterprise_assertion_invalid, or
     enterprise_assertion_principal_mismatch).

  9.20.  Step 12: Accept

     If all preceding steps pass without rejection, the Relying Party MUST
     accept the token and grant the requested access.

  9.21.  Step Execution Token Validation Profile

     A Step Execution Token (SET) is a Registry-issued JWT.  It MUST NOT
     be validated by applying Credential Token Step 2 and Step 3
     literally, because its iss is the Registry ID and its kid is a
     Registry step-execution key URI, not a did:aip agent key.  A Relying
     Party that receives a token for Approval Envelope step execution MUST
     use this profile before applying Step 10a.

     1.   Parse the token as a JWT per Step 1.

     2.   Decode the JOSE header and payload without using either for
          acceptance.  The payload MUST conform to step-execution-
          token.schema.json.  The iss claim MUST be an HTTPS Registry ID
          URI, sub MUST be the actor AID, and aip_approval_id and
          aip_step_kind MUST both be present.  When aip_step_kind is
          "forward", aip_approval_step MUST be present and
          aip_compensation_step MUST be absent.  When aip_step_kind is
          "compensation", aip_compensation_step MUST be present and
          aip_approval_step MUST be absent.  If aip_registry is present,
          it MUST equal iss.  If any of these checks fail, reject with
          invalid_token.






  Singla                  Expires 15 November 2026               [Page 94]


  Internet-Draft                     AIP                          May 2026


     3.   Validate the SET header. typ MUST be "AIP-SET+JWT", alg MUST be
          "EdDSA", and kid MUST be an HTTPS URI whose origin matches the
          iss Registry ID origin.  The protected header MUST also contain
          integer aip_trv.  If any check fails, reject with invalid_token.

     4.   Apply the expiration preflight from Step 2a.

     5.   Resolve the issuing Registry trust state from local pinned trust
          records only.  The Relying Party MUST have previously completed
          first-contact bootstrap or sequential trust update for the iss
          Registry ID under Section 7.4.4 and Section 7.4.7.1.  It MUST
          select the locally retained Registry Trust Record whose
          signed.registry_id equals iss and whose signed.version equals
          the SET protected header aip_trv.  The Relying Party MUST NOT
          fetch /v1/registry-metadata or a Registry Trust Record during
          SET validation to establish trust for the SET being validated.
          If no matching pinned trust record exists, or if the pinned
          trust record is expired and has not already been refreshed by a
          completed trust-update procedure, reject with
          registry_untrusted.

     6.   The SET header kid MUST exactly match the keyid of a JWK listed
          in active_verification_keys.step_execution of the accepted
          Registry Trust Record version.  If no such key is listed, reject
          with invalid_token.

     7.   Verify the SET signature using the matched step-execution JWK.
          If signature verification fails, reject with invalid_token.

     8.   Apply Steps 5a through 5f and Step 6 to the SET common claims.
          Step 5g is replaced for SETs by the following SET-specific
          binding: the payload iss MUST be the HTTPS Registry ID whose
          pinned Registry Trust Record was selected by protected header
          aip_trv; the payload sub MUST match the did:aip ABNF and
          identify the actor AID; and the protected header kid MUST
          identify a Registry step-execution key listed in that selected
          Trust Record.  The SET replay cache is keyed by (iss, jti),
          where iss is the Registry ID.  A Registry MUST generate SET jti
          values that are unique within that Registry ID across all issued
          Step Execution Tokens.  Registry complete/fail endpoints MAY
          return a stored idempotent response for an exact retry of a
          previously completed transition, but MUST NOT re-execute the
          transition or accept a replayed SET as fresh authority.








  Singla                  Expires 15 November 2026               [Page 95]


  Internet-Draft                     AIP                          May 2026


     9.   Apply Step 6a when required, treating the SET issuer Registry
          iss as the Registry whose trust anchor is being verified.  For
          Tier 2 or Tier 3 operations, or whenever aip_registry is
          present, the root principal DID Document's AIPRegistry service
          endpoint MUST match the SET issuer Registry by origin
          comparison.

     10.  Apply Step 6b to any aip_engagement_id, using sub as the actor
          AID whose engagement participation is being checked.

     11.  Apply Step 7 to the actor AID in sub, not to the Registry ID in
          iss.  Apply Step 8 to aip_chain, except that Step 8 Post-Check A
          and B are replaced by the rule that aip_chain[n-1].sub MUST
          equal the SET sub.

     12.  Apply Steps 9 through 9d using the actor AID in sub as the
          effective agent AID for manifest lookup, scope verification,
          delegation inheritance, and Grant Tier Conformance.

     13.  Apply Step 10 when DPoP is required.  For SETs, the DPoP proof
          key MUST match public key material controlled by the actor AID
          in sub, not the Registry step-execution key that signed the SET.

     14.  Apply Step 10a, Step 11 using sub as the effective actor AID,
          and Step 12.

     A token with typ: "AIP+JWT" MUST NOT be accepted as a Step Execution
     Token.  A token with typ: "AIP-SET+JWT" MUST NOT be accepted as an
     agent-issued Credential Token.  This type separation prevents
     substitution between agent-issued and Registry-issued authorisation
     artifacts.

  10.  Delegation

     AIP enables hierarchical delegation where a principal authorizes a
     primary agent, which may in turn authorize sub-agents under narrowing
     scope constraints.  Delegation is encoded in the aip_chain array of
     the Credential Token, with each Principal Token in the chain
     representing one delegation hop from principal to agent.

  10.1.  Delegation Chain

     Every Credential Token MUST include a verifiable principal chain
     linking the acting agent to its root principal via the aip_chain
     array.  The root principal MUST be a human or organizational entity
     identified by a W3C Decentralized Identifier (DID) that does NOT use
     the did:aip method.  Subject to the Tier-specific Principal DID
     Method requirements in Section 20, did:web, did:key, or proprietary



  Singla                  Expires 15 November 2026               [Page 96]


  Internet-Draft                     AIP                          May 2026


     DID methods can be acceptable for Tier 1.

     The maximum delegation depth is a hard constraint of 10.  Delegation
     depth is the zero-based delegation_depth value carried in each
     Principal Token and MUST equal that token's index in the aip_chain
     array.  A valid chain therefore contains at most 11 Principal Tokens:
     indexes 0 through 10.  An agent MUST NOT delegate to a sub-agent if
     doing so would create a token with delegation_depth greater than 10
     or an aip_chain longer than 11 elements.

     An agent MUST NOT delegate to itself.  For every delegated Principal
     Token with delegation_depth greater than 0, the delegated_by AID MUST
     identify the immediate parent agent and MUST NOT equal the token's
     sub AID.  Relying Parties enforce this prohibition during Step 8e and
     Step 8g of Credential Token validation.

     The default value of max_delegation_depth MUST NOT exceed 3.  When a
     Principal Token does not explicitly set max_delegation_depth,
     implementations MUST treat the default as 3.  This conservative
     default prevents accidental authorization chains from becoming
     unmanageably deep; parties requiring deeper chains MUST explicitly
     opt in by setting max_delegation_depth to a value greater than 3 and
     no greater than 10.

  10.2.  Capability Scope Rules

     Scope inheritance is the mechanism by which child agents are
     constrained to operate within the bounds of their parent's
     authorization.  Five core rules (D-1 through D-5) govern this
     relationship; they are defined in Section 5.10 of the AIP
     specification.

     *Scope Inheritance Rule:* For each scope s granted to a child agent,
     s MUST be present in the parent's Capability Manifest AND all
     constraint values for s in the child's manifest MUST be equal to or
     more restrictive than the corresponding values in the parent's
     manifest.

     Constraint comparison uses the recursive attenuation semantics from
     Rule CO-1.  Numeric caps and thresholds use the ordering defined for
     that field; booleans, arrays, strings, enums, omitted fields, and
     unknown types follow the type-specific CO-1 rules.









  Singla                  Expires 15 November 2026               [Page 97]


  Internet-Draft                     AIP                          May 2026


     Implementations MUST enforce this rule at delegation time -- when a
     child agent is registered, the Registry MUST validate that all scopes
     in its Capability Manifest satisfy the inheritance rule relative to
     its immediate parent's manifest.  Implementations MAY reject
     delegation requests that violate this rule before they are
     registered.

     Relying Parties MUST independently verify this rule during validation
     using the ordered Step 9c algorithm in the Credential Token
     validation algorithm (see Section 9.15).  This ensures that even if a
     Registry incorrectly permits a violating delegation, Relying Parties
     will catch it and reject the token.

  10.3.  Delegation Validation

     When validating a delegated Credential Token, Relying Parties MUST
     fetch and verify the Capability Manifests of all agents in the
     delegation chain.  This section specifies the performance and caching
     constraints for these operations.

     *Ancestor Manifest Fetch Limits:* Implementations MUST NOT fetch more
     ancestor manifests than the max_delegation_depth value of the chain's
     root token (which defaults to 3 when absent).  This limit prevents
     accidental O(n^2) fetch patterns in deep delegation chains and bounds
     the performance cost of validation.

     *Ancestor Manifest Caching for Tier 1:* For Tier 1 operations (low-
     risk scopes with bounded-staleness threat model), ancestor manifests
     MAY be cached for a maximum of 60 seconds.  This cache is per-agent
     and per-manifest, and MUST respect the 60-second TTL.  After 60
     seconds, the Relying Party MUST fetch a fresh manifest.

     *No-Cache Requirement for Tier 2:* For Tier 2 operations (high-risk
     scopes with real-time threat model), the no-cache requirement in the
     Credential Token validation algorithm (see Section 9.15) applies to
     ALL manifests in the delegation chain -- including ancestor manifests
     -- not only the leaf agent's manifest.  The 60-second ancestor cache
     MUST NOT be used for any manifest appearing in a Tier 2 validation.
     Every manifest MUST be fetched fresh from the Registry.

     *Unavailable Manifests:* If an ancestor manifest is unavailable or
     cannot be fetched (due to network failure, Registry downtime, or the
     manifest having been deleted), the Relying Party MUST reject the
     token by returning the error code manifest_invalid.  Partial
     delegation chains are not acceptable; either all manifests in the
     chain are available and valid, or the token is rejected.





  Singla                  Expires 15 November 2026               [Page 98]


  Internet-Draft                     AIP                          May 2026


  10.4.  Delegated Identity Chaining for A2A Workflows

     Agent-to-agent asynchronous workflows require Relying Parties to
     distinguish the acting agent from the originating agent that
     delegated the work.  When Agent B makes a tool call on behalf of
     Agent A, Agent B's Credential Token MUST carry both identities using
     the profile in this section.

     1  Agent B's Credential Token aip_chain array MUST include Agent A's
        Principal Token as an additional chain element after Agent B's own
        root Principal Token.

     2  The aip_scope in Agent B's Credential Token MUST be a strict
        subset of the scopes granted in Agent A's Capability Manifest.
        Rule D-1 enforces this at delegation time; this rule applies the
        same attenuation requirement to the presented Credential Token.

     3  When Agent B is acting in a delegated A2A context, Agent B's
        Credential Token MUST include the aip_originator_aid claim.  The
        value of aip_originator_aid MUST be Agent A's AID: the AID of the
        agent that initiated the workflow and delegated the task to Agent
        B.  The aip_originator_aid value MUST conform to the did:aip ABNF
        defined in Section 4.1.  The aip_originator_aid value MUST NOT
        equal the sub claim of Agent B's Credential Token.  When
        aip_originator_aid is present but does not meet these constraints,
        the Relying Party MUST reject the request with
        a2a_originator_invalid.

     4  Relying Parties MAY use aip_originator_aid to apply originator-
        level access policies and to index audit events by the originating
        agent.  Full chain validation under Section 9.11 remains REQUIRED
        for every accepted Credential Token.

     5  Relying Parties receiving a Credential Token that contains
        aip_originator_aid MUST perform the following validation:

        a.  Verify aip_originator_aid conforms to the did:aip ABNF in
            Section 4.1.  If not, reject with a2a_originator_invalid.

        b.  Verify aip_originator_aid does not equal the Credential Token
            sub claim.  If equal, reject with a2a_originator_invalid.

        c.  Verify aip_originator_aid appears as the sub of aip_chain[0]
            or as a registered AID in the validated delegation chain, so
            that Agent A is demonstrably the originator of the chain.  If
            no such binding exists, reject with a2a_originator_invalid.





  Singla                  Expires 15 November 2026               [Page 99]


  Internet-Draft                     AIP                          May 2026


        d.  Relying Parties MAY use aip_originator_aid to apply
            originator-level access policies and audit classification for
            the already validated request context.  Every new Credential
            Token or Step Execution Token presented on a downstream call
            MUST still pass the full validation algorithm, including
            Section 9.11.

     This profile aligns with RFC 8693 actor-token semantics: the signing
     Credential Token identifies the current actor, while
     aip_originator_aid and the additional Principal Token context allow
     enterprise audit systems to attribute tool calls to the originating
     agent chain.

     Relying Parties that support enterprise audit logging SHOULD record
     aip_originator_aid in their audit trail as the chain originator for
     all A2A tool calls.

  11.  Revocation Management

     Revocation provides the kill switch for agent identity.  When an
     agent is revoked, its Credential Tokens and Step Execution Tokens
     MUST be rejected as soon as the applicable revocation check observes
     the active revocation.  Tier 2 and Tier 3 checks are live and fail
     closed on Registry unavailability.  Tier 1 uses bounded-staleness
     CRLs, so enforcement can lag until the next fresh CRL within the SLA
     defined in this section.

  11.1.  Revocation Object

     Revocation is performed by submitting a signed Revocation Object to
     POST /v1/revocations.  The Revocation Object fields, required
     members, type enum, and signing input are defined only in
     Section 5.7.  This section defines processing effects for accepted
     Revocation Objects; it does not define a second Revocation Object
     schema.

     A principal_revoke with a Principal DID target invalidates every
     Credential Token and Step Execution Token whose
     aip_chain[0].principal.id equals that Principal DID.  A
     principal_revoke with an AID target invalidates every token whose
     aip_chain depends on that AID's principal authorisation.  This effect
     is independent of propagate_to_children.  The propagate_to_children
     flag controls whether the Registry also materialises descendant
     Revocation Objects; it does not limit the validity effect of
     principal_revoke.






  Singla                  Expires 15 November 2026              [Page 100]


  Internet-Draft                     AIP                          May 2026


  11.2.  Revocation Submission Validation

     A conformant Registry MUST implement POST /v1/revocations for
     externally submitted Revocation Objects.  The request body MUST be a
     JSON object conforming to revocation-object.schema.json.  Unless a
     check below specifies a more precise error code, failed validation
     MUST be rejected with revocation_invalid.

     The Registry MUST perform the following checks in order:

     1.  The request MUST use Content-Type: application/json.  The object
         MUST contain all required Revocation Object members, including
         kid.  If propagate_to_children is absent, the Registry MUST
         process it as false.

     2.  If revocation_id was already accepted, the Registry MUST compare
         the Section 2.1 canonical JSON serialization of the submitted
         object to the stored object.  If they are identical, the Registry
         MUST return HTTP 200 with the stored Revocation Object and MUST
         NOT apply side effects again.  If they differ, the Registry MUST
         reject with revocation_conflict.

     3.  The timestamp value MUST be a valid UTC date-time and MUST NOT be
         more than 300 seconds in the future relative to the Registry's
         current clock.  Registries MAY accept older timestamps, but the
         revocation_id uniqueness check remains mandatory.

     4.  The reason value MUST be one of the reason codes in the
         Revocation Object schema.  Externally submitted Revocation
         Objects MUST NOT use parent_revoked, heartbeat_timeout, or
         lifecycle_expired; those reason codes are reserved for Registry-
         generated Revocation Objects.

     5.  For full_revoke, scope_revoke, and delegation_revoke, target_id
         MUST be a registered did:aip AID in the authoritative Registry.
         Unknown targets MUST be rejected with unknown_aid.  For
         principal_revoke, target_id MUST be either a registered AID or a
         Principal DID associated with at least one stored registration in
         that Registry.

     6.  For scope_revoke, scopes_revoked MUST be present and non-empty,
         and every entry MUST be an active synced AIP Scope Catalog scope
         or an accepted local/private extension scope that is currently
         granted by the target's effective Capability Manifest.  Invalid
         scope entries MUST be rejected with invalid_scope.  For all other
         revocation types, scopes_revoked MUST be absent.





  Singla                  Expires 15 November 2026              [Page 101]


  Internet-Draft                     AIP                          May 2026


     7.  The Registry MUST construct the target authorization chain from
         its registration records.  That chain consists of the target's
         root Principal DID and every ancestor AID recorded through the
         parent-child delegation index.  For full_revoke, scope_revoke,
         and delegation_revoke, issued_by MUST equal either the target's
         root Principal DID or an ancestor AID in that chain.  For
         principal_revoke targeting a Principal DID, issued_by MUST equal
         that Principal DID.  For principal_revoke targeting an AID,
         issued_by MUST equal the target AID's root Principal DID.
         Unauthorized issuers MUST be rejected with
         revocation_unauthorized.

     8.  For a DID issuer, kid MUST be a DID URL whose DID portion equals
         issued_by.  The Registry MUST resolve the DID, locate the Ed25519
         verification method named by kid, and verify the Revocation
         Object signature over the Section 5.7 signing input.  For a
         did:aip issuer, the key lookup MUST use the authoritative
         Registry public-key endpoint for the referenced AID and key
         version.  If the key cannot be resolved, is not Ed25519, is not
         controlled by issued_by, or the signature fails, the Registry
         MUST reject with revocation_invalid.

     Registry-generated Revocation Objects are not externally submitted
     through the public POST /v1/revocations endpoint.  For
     parent_revoked, heartbeat_timeout, and lifecycle_expired, the
     Registry MUST set issued_by to its registry_id, set kid to a JWK
     listed in active_verification_keys.crl of the Registry Trust Record
     current at the Revocation Object timestamp, and sign the object with
     the corresponding private key.

     Acceptance MUST be atomic.  On success, the Registry MUST store the
     Revocation Object immutably, update live revocation status, schedule
     CRL publication within the 15-minute freshness window defined in
     Section 11.3, and return HTTP 201 with Content-Type: application/json
     and the stored Revocation Object.  If propagate_to_children is true,
     the Registry MUST recursively materialise child Revocation Objects
     with reason parent_revoked within 15 seconds.  For principal_revoke,
     token invalidation does not depend on materialised child objects;
     propagation only adds audit and index records.

  11.3.  Certificate Revocation List (CRL)

     The Registry MUST expose a canonical origin CRL endpoint at GET /v1/
     crl and MUST publish the preferred CRL retrieval URI as endpoints.crl
     in both /v1/registry-metadata and the signed Registry Trust Record.
     The published endpoints.crl value MAY be /v1/crl or an absolute HTTPS
     URI for a CDN or distributed object store.  Relying Parties MUST
     retrieve CRL documents from the accepted Registry Trust Record's



  Singla                  Expires 15 November 2026              [Page 102]


  Internet-Draft                     AIP                          May 2026


     signed.endpoints.crl value rather than assuming registry_id + "/v1/
     crl".

     The CRL MUST be updated within 15 minutes of a new Revocation Object
     being accepted.  The published CRL retrieval URI MUST be served from
     a CDN or distributed infrastructure.  CDN and object-store
     distribution is not a trust anchor: CRL documents MUST be signed by a
     JWK listed in active_verification_keys.crl of the Registry Trust
     Record version current at issuance time.

     The CRL is an AIP signed JSON document, not an X.509 CRL.  A
     successful CRL response MUST use Content-Type: application/aip-
     crl+json and MUST conform to crl.schema.json.  The top-level object
     MUST contain signed and signatures.  The signed object MUST include
     registry_id, trust_record_version, crl_id, issued_at, next_update,
     sequence, publication_mode, revocation_count, and revocations.  The
     publication_mode value MUST be "complete", "index", or "segment".  In
     "complete" mode, the revocations array contains the full signed
     Revocation Objects active for bounded-staleness validation at
     issued_at.  In "index" mode, the revocations array MUST be empty and
     the signed object MUST contain segments as defined in Section 17.10.
     In "segment" mode, the revocations array contains only the Revocation
     Objects assigned to that segment, and the signed object MUST contain
     segment_id.

     The CRL signing input is the RFC 8785 JSON Canonicalization Scheme
     (JCS) serialization of the signed object only.  Each signature entry
     MUST contain keyid and sig.  The keyid MUST match a JWK keyid in
     active_verification_keys.crl for the Registry Trust Record whose
     signed.version equals the CRL signed.trust_record_version.  The
     signature algorithm is EdDSA over Ed25519.  A Relying Party MUST
     reject an unsigned, malformed, or unverifiable CRL and MUST NOT treat
     CDN integrity, TLS termination, or object-store metadata as a
     substitute for this signature verification.

     CRL consumers MUST verify that signed.registry_id equals the accepted
     Registry Trust Record's signed.registry_id, that
     signed.trust_record_version identifies an accepted Registry Trust
     Record, and that at least one signature verifies under that trust
     record's active_verification_keys.crl.  The next_update timestamp
     MUST be no later than 15 minutes after issued_at.  Relying Parties
     MUST NOT use a CRL for new token validations after next_update; if no
     fresh verifiable CRL is available when one is required, validation
     MUST fail with registry_unavailable.

     CRL documents MUST include active principal_revoke entries by
     target_id.  For Tier 1 validation, Relying Parties MUST check
     principal_revoke entries whose target_id equals the token's root



  Singla                  Expires 15 November 2026              [Page 103]


  Internet-Draft                     AIP                          May 2026


     Principal DID and entries whose target_id equals any AID in the
     token's validated aip_chain.  A matching principal_revoke is
     equivalent to agent_revoked for that token.

  11.4.  Revocation Checking

     A token's Tier is determined by its highest-risk scope.  A token with
     one Tier 2 scope and any number of Tier 1 scopes is a Tier 2 token.

     *Tier 1 - Bounded-staleness:* The Credential Token TTL is the
     effective catalog-derived TTL defined in Section 8.2.  Relying
     Parties validate revocation status at request validation time using a
     verifiable CRL whose next_update has not passed.  A Relying Party
     MUST refresh its cached CRL before using it for new validations after
     next_update.

     *Tier 2 - Real-time revocation:* Applies when the highest synced AIP
     Scope Catalog tier among requested scopes is 2.  Real-time Registry
     check on EVERY request.  MUST NOT cache revocation status.  DPoP MUST
     be verified for the request regardless of per-scope requires_dpop
     metadata.  If Registry unreachable: MUST deny and return
     registry_unavailable.

     The live Tier 2 lookup uses GET /v1/agents/{aid}/revocation.  A
     registered AID returns HTTP 200 whether or not it is revoked.  The
     response body is the Revocation Status response defined in
     Section 17.8.  Unknown AIDs return unknown_aid (HTTP 404).

     *Tier 3 - Enterprise:* MUST use mTLS.  MUST support OCSP per RFC
     6960.  Tier 3 supplements, not replaces, Tier 2.

     *Child Agent Propagation:* When the Registry processes a Revocation
     Object with propagate_to_children: true, the Registry MUST
     recursively revoke descendants within 15 seconds.  A principal_revoke
     invalidates dependent tokens regardless of this flag; propagation
     only controls whether descendant Revocation Objects are written for
     indexing, CRL compactness, and auditability.

     Replica Registries MUST synchronise within 45 seconds.  Combined end-
     to-end propagation MUST NOT exceed 60 seconds.

     *Approval Envelope interaction:* When an agent AID is revoked, the
     Registry MUST transition all Approval Envelopes in pending_approval,
     approved, or executing status to failed.  Unclaimed steps for that
     actor MUST be marked failed.  In-progress claims MUST be treated as
     failed; the Registry MUST initiate compensation if applicable.





  Singla                  Expires 15 November 2026              [Page 104]


  Internet-Draft                     AIP                          May 2026


  11.5.  Registry Push Notification Protocol (RPNP)

     RPNP is an OPTIONAL Registry capability for real-time revocation
     event delivery.

  11.5.1.  Overview

     When RPNP is implemented:

     *  Registry MUST start the first push delivery attempt within 5
        seconds of the event commit time defined in Section 11.5.4

     *  Push payloads MUST be signed by a JWK listed in
        active_verification_keys.notifications of the Registry Trust
        Record version current at issuance time

     *  Subscriber authentication MUST be verified at subscription time

     For subscribing Relying Parties, the effective revocation
     notification window is the RPNP first-attempt latency (at most 5
     seconds) rather than the CRL refresh interval.  RPNP does not replace
     CRL; it supplements it.  Confirmed delivery depends on subscriber
     availability and the retry rules in Section 11.5.4.

  11.5.2.  Subscription

     A Relying Party subscribes by calling POST /v1/subscriptions:

     The request body MUST conform to the subscription_request definition
     in rpnp.schema.json.  On success, the Registry assigns a
     subscription_id with the pattern sub:<uuid-v4> and returns HTTP 201
     with a body conforming to the subscription_response definition in
     rpnp.schema.json.


















  Singla                  Expires 15 November 2026              [Page 105]


  Internet-Draft                     AIP                          May 2026


      +=========================+=============+=========================+
      | Field                   |   Required  | Constraints             |
      +=========================+=============+=========================+
      | subscriber_did          | REQUIRED    | MUST be did:web or      |
      |                         |             | did:aip                 |
      +-------------------------+-------------+-------------------------+
      | event_types             | REQUIRED    | Array containing one or |
      |                         |             | more of full_revoke,    |
      |                         |             | scope_revoke,           |
      |                         |             | delegation_revoke,      |
      |                         |             | principal_revoke, and   |
      |                         |             | engagement_cancelled    |
      +-------------------------+-------------+-------------------------+
      | scope_filter            | REQUIRED    | aid, principal, or all  |
      +-------------------------+-------------+-------------------------+
      | targets                 | CONDITIONAL | REQUIRED when           |
      |                         |             | scope_filter is aid or  |
      |                         |             | principal               |
      +-------------------------+-------------+-------------------------+
      | webhook_uri             | REQUIRED    | HTTPS URI               |
      +-------------------------+-------------+-------------------------+
      | hmac_secret             | REQUIRED    | Base64url-encoded       |
      |                         |             | shared secret; minimum  |
      |                         |             | 32 bytes of entropy     |
      +-------------------------+-------------+-------------------------+
      | subscription_expires_at | REQUIRED    | ISO 8601 UTC; max 90    |
      |                         |             | days                    |
      +-------------------------+-------------+-------------------------+

                         Table 19: Subscription Fields

     The subscription request MUST be authenticated via DPoP proof bound
     to subscriber_did.  A DPoP proof that only proves possession of an
     arbitrary key is not sufficient subscription authentication.  If the
     DPoP proof is absent, malformed, unverifiable, replayed, not bound to
     subscriber_did, or not bound to the current request target, the
     Registry MUST reject with subscription_auth_required.

     The Registry MUST accept exactly the following RPNP subscription
     authentication profiles:

     1  *DID-bound DPoP:* The DPoP proof protected header MUST contain a
        public verification key and a DID URL key identifier in jwk.kid.
        The DID portion of jwk.kid MUST equal subscriber_did.  The
        Registry MUST resolve subscriber_did and verify that jwk.kid
        identifies an Ed25519 verification method controlled by that DID.
        For did:web, resolution uses the DID method's normal DID Document
        resolution.  For did:aip, resolution uses the authoritative AIP



  Singla                  Expires 15 November 2026              [Page 106]


  Internet-Draft                     AIP                          May 2026


        Registry public-key endpoint for the referenced AID and key
        identifier.  The public key in the DPoP header MUST be byte-for-
        byte equivalent to the resolved verification method, and the DPoP
        proof signature MUST verify under that key.

     2  *Authorization-bound DPoP:* The request MAY include Authorization:
        DPoP <token>.  In that case, the Registry MUST validate the token
        using Section 9 with the subscription endpoint as the audience,
        MUST validate the DPoP proof using Section 9 Step 10 including the
        ath check, and MUST verify that the token issuer, token subject,
        and leaf aip_chain subject all equal subscriber_did.  This profile
        is available only when subscriber_did is a did:aip AID.

     For either profile, the Registry MUST verify htm, htu, iat, and jti
     replay state using the DPoP validation rules in Section 9 Step 10.
     In DID-bound DPoP without an Authorization header, the ath claim MUST
     be absent.  If an Authorization header is present, ath MUST be
     present and valid for that exact token.

     The Registry MUST authorize the requested scope_filter against the
     authenticated subscriber_did.  If scope_filter is "all" and the
     subscriber is not explicitly authorized by Registry policy for global
     revocation notifications, the Registry MUST reject the request with
     subscription_scope_forbidden.  If scope_filter is "aid" or
     "principal", every value in targets MUST be within the subscriber's
     authorized observation set; otherwise, the Registry MUST reject with
     subscription_scope_forbidden.

     The Registry MUST enforce configured per-subscriber and global active
     subscription quotas before accepting a new subscription.  If
     accepting the request would exceed any applicable quota, the Registry
     MUST reject with subscription_limit_exceeded.  The Registry SHOULD
     include Retry-After when quota exhaustion is temporary.

     The hmac_secret value is shared secret material used by the Registry
     to authenticate push event delivery.  The value MUST be transmitted
     only over TLS.  The Registry MUST retain the secret, or a reversibly
     encrypted form of the secret, for the lifetime of the subscription so
     it can compute delivery HMACs.  A Registry MUST NOT store only a one-
     way hash of this value while the subscription remains active.
     Registries MAY additionally store a hash of the secret for audit or
     lookup purposes, but that hash is not sufficient to sign delivery
     requests.

     GET /v1/subscriptions/{id} MUST return the current
     subscription_response object.  The status field MUST be one of
     active, degraded, cancelled, or expired.  Status responses MUST
     include consecutive_failures, last_delivery_attempt_at,



  Singla                  Expires 15 November 2026              [Page 107]


  Internet-Draft                     AIP                          May 2026


     last_success_at, next_retry_at, and last_delivery_status, using null
     for timestamp fields that have not yet occurred.  DELETE /v1/
     subscriptions/{id} MUST atomically transition an active or degraded
     subscription to cancelled and return the updated
     subscription_response.

  11.5.3.  Push Event Payload

     Push events are delivered as HTTP POST to the subscriber's
     webhook_uri.  The body is a compact-serialised JWT signed by a JWK
     listed in active_verification_keys.notifications of the Registry
     Trust Record version current at issuance time.

       +=========+=====================================================+
       | Header  | Value                                               |
       | Field   |                                                     |
       +=========+=====================================================+
       | typ     | AIP-RPNP+JWT                                        |
       +---------+-----------------------------------------------------+
       | alg     | EdDSA                                               |
       +---------+-----------------------------------------------------+
       | kid     | Registry notification key ID                        |
       +---------+-----------------------------------------------------+
       | aip_trv | Integer Registry Trust Record version whose         |
       |         | active_verification_keys.notifications contains kid |
       +---------+-----------------------------------------------------+

                           Table 20: RPNP JWT Fields

     The protected aip_trv header is used to select an already pinned
     Registry Trust Record for the event issuer.  Subscribers MUST NOT
     fetch new trust state during push-event validation to establish trust
     for that event.


















  Singla                  Expires 15 November 2026              [Page 108]


  Internet-Draft                     AIP                          May 2026


             +=================+=================================+
             | Payload Field   | Description                     |
             +=================+=================================+
             | iss             | Registry ID                     |
             +-----------------+---------------------------------+
             | sub             | Affected AID or engagement ID   |
             +-----------------+---------------------------------+
             | iat             | Unix timestamp                  |
             +-----------------+---------------------------------+
             | exp             | Unix timestamp; MUST be no more |
             |                 | than 300 seconds after iat      |
             +-----------------+---------------------------------+
             | jti             | UUID v4; unique event ID        |
             +-----------------+---------------------------------+
             | subscription_id | Subscription identifier         |
             |                 | receiving this push event       |
             +-----------------+---------------------------------+
             | event_type      | One of subscribed types         |
             +-----------------+---------------------------------+
             | event_data      | Event-specific data             |
             +-----------------+---------------------------------+

                         Table 21: RPNP Payload Fields

     The JWT payload MUST conform to the push_payload definition in
     rpnp.schema.json.  The request MUST include an X-AIP-Signature header
     using this exact syntax:

     X-AIP-Signature: <sig-header>

     sig-header = "v1;t=" timestamp ";kid=" subscription-id ";h=" hmac

     The HMAC input is the ASCII decimal t value, followed by a period
     (.), followed by the exact request body octets.  The h value is
     BASE64URL(HMAC-SHA256(hmac_secret, input)) without padding.  The kid
     value MUST equal the JWT subscription_id.  The subscriber MUST verify
     the Registry JWT signature, the HMAC, and the subscription binding
     before accepting the event.

     Subscribers MUST reject a push event if the header timestamp t is
     more than 300 seconds from the subscriber's current clock, if the JWT
     exp is in the past, if exp - iat exceeds 300 seconds, or if the jti
     has already been accepted for the same subscription_id.  Subscribers
     MUST retain replay state keyed by (subscription_id, jti) at least
     until the later of the JWT exp time and 300 seconds after receipt.






  Singla                  Expires 15 November 2026              [Page 109]


  Internet-Draft                     AIP                          May 2026


  11.5.4.  Delivery Guarantees

     RPNP provides at-least-once best-effort push delivery.  It does not
     provide exactly-once delivery, and subscribers MUST use the jti
     replay rules in this section to make event processing idempotent.

     1.  The Registry MUST record an event_committed_at instant using its
         reliable UTC clock when the state transition that creates the
         push event is durably committed.  For revocation events, this is
         the instant at which the Revocation Object is accepted and live
         revocation status is committed.  For engagement cancellation
         events, this is the instant at which the cancellation state
         transition is committed.

     2.  The Registry MUST start the first HTTPS POST delivery attempt to
         each active matching subscription no later than 5 seconds after
         event_committed_at.  The interval ends when the Registry begins
         sending the request to the subscriber's webhook_uri.  This
         5-second requirement applies to the first delivery attempt, not
         to confirmed successful receipt.

     3.  The Registry MUST set last_delivery_attempt_at to the Registry
         UTC time at which each delivery attempt begins.  If the first
         attempt starts more than 5 seconds after event_committed_at, the
         Registry MUST record last_delivery_status as
         first_attempt_sla_missed until a later delivery attempt
         overwrites it with a more recent status.

     4.  On delivery failure, meaning timeout or any non-2xx HTTP
         response, the Registry MUST perform at least three retry attempts
         after the initial delivery attempt, using exponential backoff
         intervals of 1s, 2s, and 4s as the minimum retry schedule.  The
         Registry MAY add jitter or continue retrying after those
         attempts, but MUST NOT schedule the first three retries later
         than those intervals unless the subscription has expired or been
         cancelled.

     5.  A delivery attempt MUST be treated as timed out if the subscriber
         does not return a final HTTP response within 5 seconds after the
         Registry finishes sending the request body, unless the Registry
         applies a shorter deployment-profile timeout.

     6.  After 3 consecutive failures, mark the subscription degraded,
         update consecutive_failures, last_delivery_attempt_at,
         last_delivery_status, and next_retry_at, and continue to make the
         event available through CRL or live revocation status.
         Subscribers MUST fall back to CRL or live Registry checks while
         the subscription is degraded.



  Singla                  Expires 15 November 2026              [Page 110]


  Internet-Draft                     AIP                          May 2026


     7.  On any successful 2xx delivery, reset consecutive_failures to 0,
         set last_success_at, clear next_retry_at, and restore status to
         active unless the subscription has expired or been cancelled.

  12.  Principal Grant Ceremony (AIP-GRANT)

     The AIP-GRANT ceremony provides a standardised protocol for
     principals to authorise AI agents.  AIP-GRANT is analogous to the
     OAuth 2.0 Authorization Code Flow [RFC6749], adapted for the agent
     identity use case.  Two independent implementations following this
     section MUST produce interoperable grant interactions.

  12.1.  Overview and Roles

     The AIP-GRANT ceremony involves three actors:

     Agent Deployer  The party that constructs the GrantRequest and
        submits the Registration Envelope to the Registry.  The deployer
        generates the agent's Ed25519 keypair before initiating the grant
        and may be the principal themselves or a service acting on the
        principal's behalf.

     Principal Wallet  Software that holds the principal's DID private key
        and executes the signing ceremony.  The Principal Wallet MUST
        verify the deployer's signature and MUST obtain explicit human
        approval before signing.

     AIP Registry  The service that accepts the Registration Envelope.
        The Registry's role is defined in Section 17; it is not modified
        by AIP-GRANT.

     The basic flow:



















  Singla                  Expires 15 November 2026              [Page 111]


  Internet-Draft                     AIP                          May 2026


        Agent Deployer      Principal Wallet      AIP Registry
              |                     |                  |
              |-- GrantRequest ---->|                  |
              | (agent_aid,         |                  |
              |  capabilities,      |                  |
              |  purpose, nonce)    |                  |
              |                     |                  |
              |             [Display consent UI]       |
              |           [Human reviews & signs]      |
              |                     |                  |
              |<-- GrantResponse ---|                  |
              | (signed             |                  |
              |  PrincipalToken)    |                  |
              |                     |                  |
              |-- Registration Envelope -------------->|
              | (identity + manifest +                 |
              |  principal_token)                      |
              |                                        |
              |<-- AID --------------------------------|

  12.2.  GrantRequest Object

     The GrantRequest is a JSON object constructed by the Agent Deployer.
     It MUST be signed by the deployer's Ed25519 key when transmitted over
     the Web Redirect or QR Code bindings.  For G2, the signed request
     MUST identify the deployer through the deployer_did field and the
     signature key MUST be bound to that DID.  The nonce MUST be
     cryptographically random and MUST contain at least 128 bits of
     entropy.

     The request MUST also include deployer_name for consent UI display.
     The deployer_name value is human-readable metadata only; it is not a
     trust anchor and MUST NOT replace verification of deployer_did and
     the signed GrantRequest envelope.

     *GrantRequest Fields:*

     grant_request_id (string; REQUIRED)
        pattern: gr:<UUIDv4-lowerhex>

     aip_version (string; REQUIRED)
        AIP protocol compatibility version; MUST be "0.3"; not the
        Internet-Draft revision

     agent_aid (string; REQUIRED)
        MUST match did:aip ABNF; pre-derived AID of the agent being
        authorised; Principal Token sub MUST equal this value




  Singla                  Expires 15 November 2026              [Page 112]


  Internet-Draft                     AIP                          May 2026


     agent_name (string; REQUIRED)
        maxLength: 64; displayed in consent UI

     agent_type (string; REQUIRED)
        registered namespace value

     model.provider (string; REQUIRED)
        displayed in consent UI

     model.model_id (string; REQUIRED)
        displayed in consent UI

     requested_capabilities (object; REQUIRED)
        Capability Manifest capabilities sub-schema

     purpose (string; REQUIRED)
        minLength: 1; maxLength: 512

     delegation_valid_for_seconds (integer; REQUIRED)
        requested maximum delegation lifetime; min: 300; max: 31536000;
        approved value MUST NOT exceed this value

     nonce (string; REQUIRED)
        minLength: 22; cryptographically random

     request_expires_at (string; REQUIRED)
        ISO 8601 UTC

     callback_uri (string; CONDITIONAL)
        REQUIRED for Web Redirect and G3 OAuth authorization requests;
        MUST use HTTPS; for G3, MUST equal the OAuth redirect_uri

     state (string; CONDITIONAL)
        REQUIRED for G3 OAuth authorization requests; echoed unchanged and
        MUST equal the OAuth state parameter

     deployer_did (string; REQUIRED)
        W3C DID of the deployer; used to verify signed GrantRequests and
        displayed in consent UI

     deployer_name (string; REQUIRED)
        minLength: 1; maxLength: 128; displayed alongside deployer_did;
        display metadata only, not a trust anchor

     deployer_public_key (object; OPTIONAL)
        JWK key hint only; MUST match the verification method resolved
        from deployer_did and MUST NOT replace DID resolution




  Singla                  Expires 15 November 2026              [Page 113]


  Internet-Draft                     AIP                          May 2026


     The deployer MUST generate the agent's AID before constructing the
     GrantRequest and MUST include that value as agent_aid.  The Principal
     Token produced from this grant MUST use the original GrantRequest
     agent_aid as its sub claim.

     *Signed GrantRequest envelope:* A GrantRequest sent directly to a
     Principal Wallet using the Web Redirect or QR Code binding MUST be
     carried as a compact JWS whose payload is the UTF-8 JSON
     serialization of the GrantRequest object.  The protected JWS header
     MUST contain typ equal to "aip-grant+jws", alg equal to "EdDSA", and
     kid as a DID URL.  The DID portion of kid MUST equal the GrantRequest
     deployer_did.  The referenced verification method MUST resolve from
     the deployer_did DID Document, MUST be controlled by deployer_did,
     and MUST be an Ed25519 signing key.  If deployer_public_key is
     present, it is a cache hint only; the Principal Wallet MUST verify
     that it is byte-for-byte equivalent to the resolved verification
     method before using it and MUST NOT trust a self-supplied key that is
     not present in the resolved DID Document.

     The same signed GrantRequest envelope format is used by the G3 OAuth
     binding.  In that case, the compact JWS is carried in the
     aip_grant_request authorization request parameter and is verified by
     the Registry acting as OAuth Authorization Server before any
     authentication or consent ceremony is started.

  12.3.  Principal Wallet Consent Requirements

     The Principal Wallet MUST implement the following requirements before
     signing any grant.

     *Nonce and expiry checks:* The Principal Wallet MUST check
     request_expires_at against the current clock.  If expired, it MUST
     reject with grant_request_expired and MUST NOT show the consent UI.
     The Principal Wallet MUST maintain a record of seen grant_request_id
     values for at least 30 days and MUST reject replays with
     grant_request_replayed.

     The Principal Wallet MUST use its own reliable UTC clock for
     request_expires_at checks and MAY allow a 30-second clock skew
     tolerance.  If the Principal Wallet's current time is more than 30
     seconds after request_expires_at, the request is expired.  If the
     Principal Wallet cannot determine reliable current UTC time, it MUST
     reject with grant_request_invalid rather than issuing a back-dated or
     future-dated Principal Token.

     *Signed request checks:* For a G2 GrantRequest, the Principal Wallet
     MUST verify the signed GrantRequest envelope before displaying the
     consent UI.  The Principal Wallet MUST reject with



  Singla                  Expires 15 November 2026              [Page 114]


  Internet-Draft                     AIP                          May 2026


     grant_request_invalid and MUST NOT show the consent UI if the request
     is unsigned, if deployer_did is absent, if the JWS kid DID does not
     equal deployer_did, if the deployer DID cannot be resolved, if the
     referenced key is not an Ed25519 signing key controlled by
     deployer_did, or if the JWS signature verification fails.

     *Mandatory display elements:* The consent UI MUST display ALL of the
     following before presenting the sign/decline choice:

     1.  Agent name (agent_name) and type (agent_type)

     2.  AI model - provider and model_id

     3.  Purpose - the purpose field verbatim

     4.  Deployer identity - deployer_name and deployer_did

     5.  All requested capabilities using trusted AIP Scope Catalog
         display metadata

     6.  Delegation validity - requested duration and the approximate
         expiry computed from delegation_valid_for_seconds using the
         Principal Wallet's current UTC clock

     7.  *Destructive Operations:* Any scope whose active AIP Scope
         Catalog entry has destructive: true MUST be highlighted in the UI
         using the mandatory two-step confirmation flow required for
         Principal Wallet conformance in Section 23.2.

     Before displaying the consent UI, the Principal Wallet MUST resolve
     requested_capabilities to the concrete requested scope identifiers
     using the scope-to-capability rules in Section 5.9 and any explicit
     private extension policy accepted by the Principal Wallet.  The
     Principal Wallet MUST use a trusted immutable AIP Scope Catalog
     Snapshot for this resolution.  For each requested scope, the
     Principal Wallet MUST find an active or experimental scope entry and
     MUST find complete trusted display metadata for the Principal
     Wallet's selected locale or for the entry's display.default_locale.
     If no trusted catalog snapshot is available, if a requested
     capability cannot be resolved to a concrete scope identifier, if the
     scope entry is unknown, removed, reserved, or outside an accepted
     private extension policy, or if the required display metadata is
     absent or incomplete, the Principal Wallet MUST reject with
     grant_request_invalid and MUST NOT show the consent UI.

     The Principal Wallet MUST NOT synthesize consent text from raw scope
     identifiers, capability field names, deployer-supplied display
     strings, generic family names, or untrusted catalog data.  The title



  Singla                  Expires 15 November 2026              [Page 115]


  Internet-Draft                     AIP                          May 2026


     value in display.strings[locale].title is the canonical human-
     readable capability string for that locale.  The Principal Wallet MAY
     also display display.strings[locale].summary, but it MUST NOT use the
     summary to replace or weaken required destructive-operation
     highlighting.

     If an issued Principal Token includes a purpose claim, the claim
     value MUST be either the exact GrantRequest purpose value or a
     shorter summary that was displayed to and approved by the principal
     before signing.  A Principal Token issuer MUST NOT include a
     deployer-supplied or issuer-generated purpose claim that was not
     presented during consent.

     *Principal Token signing profile:* For a root Principal Token, the
     token issuer is always the root principal identified by principal.id.
     A Principal Wallet or other principal-controlled signing component
     that constructs a root Principal Token after consent MUST sign the
     JWT with EdDSA, MUST set iss to principal.id, and MUST use a JOSE
     header kid identifying an Ed25519 verification method controlled by
     principal.id.  A Registry or authorization server MAY prepare the
     payload, mediate consent, collect high-assurance authentication
     context, store the GrantResponse, or deliver the signed token, but it
     MUST NOT sign a root Principal Token with a Registry-controlled or
     authorization-server-controlled key and MUST NOT set iss to the
     Registry or authorization server.  The Principal Token payload sub
     claim MUST equal the agent_aid value from the original GrantRequest.
     A service that cannot obtain a principal-controlled Ed25519 signature
     MUST NOT issue a root Principal Token with that principal as iss.

     *Delegation expiry derivation:* The Principal Token issuer MUST
     compute a single issuance timestamp from its current reliable UTC
     clock at the moment of signing.  It MUST set the Principal Token
     issued_at claim and the GrantResponse signed_at field to that same
     instant.  The approved delegation lifetime MUST be represented as
     approved_delegation_valid_for_seconds, MUST be at least 300 seconds,
     and MUST NOT exceed the original GrantRequest
     delegation_valid_for_seconds.  The issuer MAY approve a shorter
     lifetime than requested.

     The Principal Token expires_at claim MUST equal issued_at plus
     approved_delegation_valid_for_seconds seconds.  No clock skew
     tolerance is applied to this calculation; clock skew tolerance
     applies only when validators compare timestamps to their local
     current time.  The issuer MUST NOT use the deployer's clock, callback
     receipt time, or request_expires_at as the Principal Token issued_at
     value.

     *Draft-02 Catalog display metadata:*



  Singla                  Expires 15 November 2026              [Page 116]


  Internet-Draft                     AIP                          May 2026


     The AIP Scope Catalog is the normative source of capability display
     metadata.  Each scope entry's display member is defined in
     Section 17.15.  For standard Draft-02 scopes, display.strings["en-
     US"].title MUST equal the display string listed below.  The
     corresponding summary value MUST be non-empty and MUST describe the
     same capability without broadening the authorization represented by
     the scope.  Extension and private scopes MUST provide equivalent
     catalog display metadata through their catalog entry or accepted
     private extension policy before a Principal Wallet can present
     consent for them.

       +======================+=======================================+
       | Scope                | Display String                        |
       +======================+=======================================+
       | email.read           | Read your email messages and metadata |
       +----------------------+---------------------------------------+
       | email.write          | Create and draft email messages       |
       +----------------------+---------------------------------------+
       | email.send           | Send email on your behalf             |
       +----------------------+---------------------------------------+
       | email.delete         | Permanently delete your email         |
       |                      | messages - this cannot be undone      |
       +----------------------+---------------------------------------+
       | calendar.read        | Read your calendar events             |
       +----------------------+---------------------------------------+
       | calendar.write       | Create and update calendar events     |
       +----------------------+---------------------------------------+
       | calendar.delete      | Delete your calendar events           |
       +----------------------+---------------------------------------+
       | filesystem.read      | Read files from your local storage    |
       +----------------------+---------------------------------------+
       | filesystem.write     | Save and modify files on your local   |
       |                      | storage                               |
       +----------------------+---------------------------------------+
       | filesystem.execute   | Execute scripts and commands on your  |
       |                      | system - HIGH RISK                    |
       +----------------------+---------------------------------------+
       | filesystem.delete    | Delete files from your local storage  |
       +----------------------+---------------------------------------+
       | web.browse           | Browse the web and read website       |
       |                      | content                               |
       +----------------------+---------------------------------------+
       | web.forms_submit     | Submit data to web forms              |
       +----------------------+---------------------------------------+
       | web.download         | Download files from the web to your   |
       |                      | system                                |
       +----------------------+---------------------------------------+
       | transactions         | Make financial transactions up to     |



  Singla                  Expires 15 November 2026              [Page 117]


  Internet-Draft                     AIP                          May 2026


       |                      | specified limits                      |
       +----------------------+---------------------------------------+
       | communicate.whatsapp | Send and receive messages via         |
       |                      | WhatsApp                              |
       +----------------------+---------------------------------------+
       | communicate.telegram | Send and receive messages via         |
       |                      | Telegram                              |
       +----------------------+---------------------------------------+
       | communicate.sms      | Send and receive SMS messages         |
       +----------------------+---------------------------------------+
       | communicate.voice    | Initiate and receive voice calls      |
       +----------------------+---------------------------------------+
       | spawn_agents.create  | Create child AI agents on your behalf |
       +----------------------+---------------------------------------+
       | spawn_agents.manage  | Monitor and manage your existing      |
       |                      | child agents                          |
       +----------------------+---------------------------------------+

               Table 22: Draft-02 Standard Scope Display Titles

  12.4.  GrantResponse Object

     The GrantResponse is constructed and signed by the Principal Wallet
     after the principal approves, partially approves, or declines the
     signing ceremony.

      +==================+=============+================================+
      | Field            |   Required  | Constraints                    |
      +==================+=============+================================+
      | grant_request_id | REQUIRED    | MUST match original request    |
      +------------------+-------------+--------------------------------+
      | nonce            | REQUIRED    | MUST match original nonce      |
      +------------------+-------------+--------------------------------+
      | status           | REQUIRED    | enum: "approved", "rejected",  |
      |                  |             | "partial"                      |
      +------------------+-------------+--------------------------------+
      | principal_id     | REQUIRED    | W3C DID of signing principal   |
      +------------------+-------------+--------------------------------+
      | principal_token  | CONDITIONAL | REQUIRED when status is        |
      |                  |             | "approved" or "partial"        |
      +------------------+-------------+--------------------------------+
      | signed_at        | REQUIRED    | ISO 8601 UTC; same instant as  |
      |                  |             | Principal Token issued_at when |
      |                  |             | principal_token is present     |
      +------------------+-------------+--------------------------------+

                         Table 23: GrantResponse Fields




  Singla                  Expires 15 November 2026              [Page 118]


  Internet-Draft                     AIP                          May 2026


     A GrantResponse with status "approved" or "partial" MUST also include
     approved_delegation_valid_for_seconds.  The value MUST be an integer
     from 300 through the original GrantRequest
     delegation_valid_for_seconds, inclusive, and is used to derive the
     Principal Token expires_at claim.

     *Deployer validation of GrantResponse:* Upon receipt the deployer
     MUST:

     1.  Verify grant_request_id matches the original request

     2.  Verify nonce matches.  If mismatch, the deployer MUST reject the
         GrantResponse with grant_nonce_mismatch; the mismatch MUST be
         treated as a forgery attempt and no agent is registered.

     3.  If status is "rejected", the deployer MUST treat the grant as a
         terminal failure with grant_rejected_by_principal and no agent is
         registered.

     4.  Verify approved_delegation_valid_for_seconds is present for
         "approved" or "partial" responses, is at least 300 seconds, and
         does not exceed the original GrantRequest
         delegation_valid_for_seconds

     5.  Decode and verify the principal_token JWT signature

     6.  Verify the principal_token payload sub exactly matches agent_aid
         from the original GrantRequest

     7.  Verify the principal_token payload issued_at represents the same
         instant as the GrantResponse signed_at

     8.  Verify signed_at and issued_at are not more than 30 seconds in
         the future relative to the deployer's current UTC clock, and that
         signed_at is not more than 24 hours in the past

     9.  Verify the principal_token payload expires_at equals issued_at
         plus approved_delegation_valid_for_seconds seconds

     If any GrantResponse validation check fails, the deployer MUST treat
     the GrantResponse as invalid and MUST NOT submit a Registration
     Envelope based on it.

     When a deployer, Registry, Principal Wallet, or authorization server
     returns an AIP error response for a rejected grant, the error code
     MUST be grant_rejected_by_principal.  When it returns an AIP error
     response for a GrantResponse whose nonce does not match the original
     GrantRequest, the error code MUST be grant_nonce_mismatch.



  Singla                  Expires 15 November 2026              [Page 119]


  Internet-Draft                     AIP                          May 2026


  12.5.  Transport Bindings

     Implementations MUST support the Web Redirect Flow.

     *Web Redirect Flow:*

     https://wallet.example.com/aip-grant
       ?request=<compact-JWS-signed-GrantRequest>
       &aip_version=0.3

     After the principal signs, the Principal Wallet delivers the
     GrantResponse:

     POST <callback_uri>
     Content-Type: application/json

     {GrantResponse JSON}

     The callback_uri MUST be pre-registered by the deployer.  Principal
     Wallets MUST NOT deliver GrantResponses to unregistered URIs.

  12.6.  Sub-Agent Delegation Flow

     When a parent agent delegates to a child agent, the parent acts as
     the delegation issuer for the child.  No new human consent UI is
     required, because the parent can only delegate scopes and constraints
     that are already within its own accepted authority.

     The child is registered with a delegated Principal Token, not a
     second root Principal Token.  The delegated token's sub is the child
     AID, delegated_by is the parent AID, and delegation_depth is the
     parent's depth plus one.  The Registry validates the submitted
     Registration Envelope using Registration Check 9 and stores the
     reconstructed parent-plus-child chain for later runtime validation.

     The parent agent MUST:

     1.  Verify requested child capabilities are a strict subset of its
         own Capability Manifest (Rule D-1)

     2.  Generate a fresh Ed25519 keypair for the child agent

     3.  Construct and sign the child's Principal Token

     4.  Construct the Registration Envelope for the child

     5.  Submit the Registration Envelope to the Registry




  Singla                  Expires 15 November 2026              [Page 120]


  Internet-Draft                     AIP                          May 2026


     6.  Provision the child's private key through a secure channel

     The parent MUST NOT retain the child's private key after successful
     provisioning.  Retaining the child's private key enables the parent
     to forge Credential Tokens in the child's name and constitutes a
     violation of the principle of least privilege.  This is a local
     implementation conformance and key-management requirement.  The
     Registry and Relying Parties cannot determine from protocol messages
     whether the parent retained a copy of the child's private key, and
     MUST NOT treat private-key deletion as a Registry acceptance check or
     Credential Token validation precondition.  Deployment profiles that
     audit this requirement MUST collect the sub-agent provisioning and
     deletion evidence defined in Section 21.4.

     For sub-agent delegation, a parent agent MAY include a purpose claim
     in the child's Principal Token to describe the delegated work.  That
     claim is signed audit metadata only.  It MUST NOT expand the child
     agent's scopes or constraints and MUST NOT be treated by Relying
     Parties as a substitute for Capability Manifest or Approval Envelope
     validation.

  12.7.  AIP-GRANT Error Codes

        +=============================+===============================+
        | Code                        | Description                   |
        +=============================+===============================+
        | grant_request_expired       | request_expires_at has passed |
        +-----------------------------+-------------------------------+
        | grant_request_replayed      | grant_request_id seen before  |
        +-----------------------------+-------------------------------+
        | grant_request_invalid       | GrantRequest malformed or     |
        |                             | signature failed              |
        +-----------------------------+-------------------------------+
        | grant_rejected_by_principal | Principal declined the grant  |
        +-----------------------------+-------------------------------+
        | grant_nonce_mismatch        | GrantResponse nonce does not  |
        |                             | match                         |
        +-----------------------------+-------------------------------+

                        Table 24: AIP-GRANT Error Codes

  12.8.  G1: Registry-Mediated Grant Flow

     The G1 (Registry-Mediated) grant profile is designed for consumer
     deployments where the agent deployer does not operate its own
     Principal Wallet integration.  The AIP Registry brokers the consent
     ceremony on the deployer's behalf.




  Singla                  Expires 15 November 2026              [Page 121]


  Internet-Draft                     AIP                          May 2026


     *Actors:* Agent Deployer, AIP Registry, Principal (via Registry-
     hosted or redirected Principal Wallet consent UI).

           Deployer               Registry              Principal
              |                      |                      |
              |-- POST /v1/grants -->|                      |
              |  (GrantRequest +     |                      |
              |   callback_uri)      |                      |
              |<-- 201 grant_id + ---|                      |
              |    wallet_redirect   |                      |
              |                      |                      |
              |-- [redirect principal to Principal Wallet URI] ------>|
              |                      |                      |
              |                      |<--- authenticates ---|
              |                      |<-- approve/decline --|
              |                      |                      |
              | [Principal-controlled signer signs token]   |
              |                      |                      |
              |<--- POST callback ---|                      |
              |    (GrantResponse)   |                      |
              |                      |                      |
              |-- GET /v1/grants/id->|                      |
              |<--- GrantResponse ---|                      |

     *Step-by-step definition:*

     1.  The deployer generates the agent's Ed25519 keypair and constructs
         a GrantRequest.  For G1, callback_uri is REQUIRED.

     2.  The deployer calls POST /v1/grants.  See example response.

     3.  The deployer redirects the principal to wallet_redirect_uri.  The
         Registry presents a consent UI.

     4.  On approval, the Registry MUST obtain a root Principal Token
         signed using the Principal Token signing profile above, with iss
         equal to the approving principal's DID and sub equal to the
         stored GrantRequest agent_aid.  The Registry MAY construct the
         unsigned payload and present it to a principal-controlled
         Principal Wallet or signing component, but the final compact JWT
         MUST be signed by an Ed25519 verification method controlled by
         principal.id.  The Registry MUST store the resulting
         GrantResponse without altering or re-signing the Principal Token.

     5.  The deployer receives the GrantResponse and submits the
         Registration Envelope to POST /v1/agents with grant_tier: "G1".





  Singla                  Expires 15 November 2026              [Page 122]


  Internet-Draft                     AIP                          May 2026


     *GET /v1/grants/{grant_id} authorisation:* Only the deployer whose
     deployer_did appears in the original GrantRequest MUST be permitted
     to retrieve the GrantResponse.

     If grant_id does not identify a stored G1 grant, or if the referenced
     grant is expired and no GrantResponse is retrievable, the Registry
     MUST reject the request with grant_not_found.

     If grant_id identifies a stored, retrievable G1 grant but the
     authenticated requester does not match the deployer_did in the
     original GrantRequest, the Registry MUST reject the request with
     grant_deployer_mismatch.

     If grant_id identifies a stored G1 grant whose principal outcome is
     "rejected", the Registry MUST reject the retrieval request with
     grant_rejected_by_principal.  If the stored GrantResponse nonce does
     not match the original GrantRequest nonce, the Registry MUST reject
     the retrieval request with grant_nonce_mismatch and MUST NOT return
     the stored GrantResponse.

  12.9.  G2: Direct Deployer Grant Flow

     The G2 (Direct Deployer) grant profile is the standard flow for
     applications that integrate directly with Principal Wallets.  The
     deployer signs the GrantRequest directly and transmits it to the
     Principal Wallet via a front-channel binding (Web Redirect or QR
     Code).

     *Actors:* Agent Deployer, Principal Wallet, Principal.

     *Step-by-step definition:*

     1.  The deployer generates the agent's Ed25519 keypair, derives the
         agent AID, and constructs a GrantRequest that includes agent_aid
         and deployer_did.

     2.  The deployer signs the GrantRequest as a compact JWS using the
         Ed25519 key identified by a kid under deployer_did.

     3.  The deployer transmits the request to the Principal Wallet via a
         front-channel binding.

     4.  The Principal Wallet resolves deployer_did, verifies the signed
         GrantRequest envelope, and presents the consent UI to the
         principal only after successful verification.






  Singla                  Expires 15 November 2026              [Page 123]


  Internet-Draft                     AIP                          May 2026


     5.  On approval, the Principal Wallet signs the Principal Token using
         the Principal Token signing profile above and returns a
         GrantResponse to the deployer's callback_uri.

     6.  The deployer submits the Registration Envelope to the Registry
         with grant_tier: "G2".

  12.10.  G3: Full Ceremony Grant Flow (OAuth 2.1)

     The G3 (Full Ceremony) grant profile is required for high-assurance
     Tier 3 operations and environments requiring identity proofing.  It
     uses an OAuth 2.1 Authorization Server (AS) typically operated by the
     Registry.

     *Actors:* Agent Deployer, AIP Registry (as OAuth AS), Principal
     Wallet, Principal.

     *OAuth binding of the GrantRequest:* Before initiating the OAuth
     authorization request, the deployer MUST construct and sign a
     GrantRequest using the signed GrantRequest envelope defined in
     Section 12.2.  The G3 OAuth authorization request MUST carry that
     compact JWS in an aip_grant_request form parameter.  The
     authorization request MUST also include response_type=code,
     client_id, redirect_uri, scope, state, code_challenge,
     code_challenge_method=S256, acr_values, and aip_version=0.3.

     POST /v1/oauth/authorize
     Content-Type: application/x-www-form-urlencoded

     response_type=code
     &client_id=did:web:assistant.example.com
     &redirect_uri=https://assistant.example.com/aip/grant-callback
     &scope=email.read%20calendar.read
     &state=sess_abc123_csrf_xyz789
     &code_challenge=<S256-code-challenge>
     &code_challenge_method=S256
     &acr_values=<requested-acr>
     &aip_version=0.3
     &aip_grant_request=<compact-JWS-signed-GrantRequest>

     The Registry Authorization Server MUST verify the signed GrantRequest
     envelope before redirecting the principal to a Principal Wallet or
     displaying any consent UI.  Verification MUST include the signed
     GrantRequest checks in Section 12.2 and the following G3 binding
     checks:

     1  The aip_grant_request parameter is present and contains a compact
        JWS whose payload is a GrantRequest object.



  Singla                  Expires 15 November 2026              [Page 124]


  Internet-Draft                     AIP                          May 2026


     2  The OAuth client_id either equals the GrantRequest deployer_did or
        identifies a pre-registered OAuth client whose Registry metadata
        maps to that same deployer_did.

     3  The OAuth redirect_uri exactly matches the GrantRequest
        callback_uri.

     4  The OAuth state exactly matches the GrantRequest state.

     5  The GrantRequest request_expires_at has not passed, allowing at
        most 30 seconds of clock skew.

     6  The OAuth scope parameter does not request authority outside the
        GrantRequest requested_capabilities.  If the Authorization Server
        cannot map a requested scope string to the GrantRequest
        capabilities under the synced AIP Scope Catalog, it MUST treat the
        authorization request as invalid.

     If any binding check fails, the Authorization Server MUST reject the
     authorization request with grant_request_invalid and MUST NOT issue
     an authorization code.  After successful verification, the
     Authorization Server MUST store an immutable authorization-code
     binding that includes the JCS hash of the GrantRequest payload, the
     compact JWS signature value, grant_request_id, agent_aid,
     deployer_did, nonce, state, callback_uri, requested_capabilities, and
     delegation_valid_for_seconds.  The token endpoint MUST use this
     stored binding when redeeming the authorization code and MUST reject
     any code that lacks such a binding with grant_request_invalid.

     *G3 token endpoint response mapping:* A successful POST /v1/oauth/
     token response for a G3 grant ceremony is an OAuth token response
     that transports, but does not replace, an AIP GrantResponse.  The
     response body MUST be a JSON object with the following fields:

     *  token_type: REQUIRED.  MUST be "AIP+JWT".

     *  access_token: REQUIRED.  The compact Principal Token JWT.  This
        value is an OAuth transport alias only.

     *  expires_in: REQUIRED.  Integer seconds until the Principal Token
        expires; MUST equal
        grant_response.approved_delegation_valid_for_seconds.

     *  state: REQUIRED.  MUST equal the OAuth state value stored in the
        authorization-code binding.






  Singla                  Expires 15 November 2026              [Page 125]


  Internet-Draft                     AIP                          May 2026


     *  grant_response: REQUIRED.  A JSON object conforming to the
        GrantResponse schema in Section 12.4 with status equal to
        "approved" or "partial".

     The access_token value MUST be byte-for-byte identical to
     grant_response.principal_token.  The deployer MUST validate the
     nested grant_response using the GrantResponse validation rules in
     Section 12.4 and MUST use grant_response.principal_token when
     constructing the Registration Envelope.  The access_token field
     exists only for OAuth client interoperability and MUST NOT be
     interpreted as replacing the principal_token field.  The Principal
     Token payload MUST include the acr and amr claims from the completed
     G3 ceremony.  If the principal rejects the grant or the ceremony
     fails before approval, the Authorization Server MUST return an OAuth
     error response and MUST NOT return a successful token response.

     *Step-by-step definition:*

     1.  The deployer constructs and signs a GrantRequest, then initiates
         an OAuth 2.1 Authorization Code Flow with PKCE at the Registry's
         authorization endpoint using the G3 OAuth binding above.

     2.  The Registry redirects the principal to their configured
         Principal Wallet for authentication and consent.

     3.  The Principal Wallet performs high-assurance authentication
         (e.g., FIDO2/WebAuthn) and obtains consent.

     4.  The Principal Wallet returns an authorization code or equivalent
         signed ceremony result to the Registry.

     5.  The Registry MUST obtain a root Principal Token signed using the
         Principal Token signing profile above by a principal-controlled
         Ed25519 verification method.  The Registry MAY prepare the token
         payload and include the high-assurance acr and amr values from
         the OAuth ceremony, but it MUST NOT sign the root Principal Token
         with the Registry's authorization-server key and MUST NOT change
         iss away from principal.id.  The token sub MUST equal the
         agent_aid value from the stored authorization-code binding, and
         the token MUST include acr and amr claims from the completed
         ceremony.

     6.  The token endpoint returns the G3 token endpoint response defined
         above.  Its grant_response member is the AIP GrantResponse used
         by the deployer for Registration Envelope construction.

     7.  The deployer submits the Registration Envelope to the Registry
         with grant_tier: "G3".



  Singla                  Expires 15 November 2026              [Page 126]


  Internet-Draft                     AIP                          May 2026


  13.  Approval Envelopes

     Approval Envelopes enable a single human approval to authorise a pre-
     declared sequence of dependent agent actions.  The principal approves
     the complete workflow graph upfront, and each Relying Party
     independently verifies its specific step against the Registry without
     requiring additional human interaction.

  13.1.  Motivation

     *The Cascading Approval Problem:* Without Approval Envelopes, multi-
     step agent workflows require the human to approve each step
     independently, eliminating the benefit of autonomous agents.  For
     example, an agent places an order with an e-commerce platform (step
     1), which triggers a payment processor (step 2).  Without Approval
     Envelopes, each step would require independent approval.

  13.2.  The Token-Expiry-While-Pending Problem

     A Credential Token with a catalog-derived TTL may expire while
     approval is pending.  Approval Envelopes decouple the approval phase
     from execution: the envelope waits in pending_approval state without
     requiring a valid token, and step-claim tokens are issued at
     execution time.

  13.3.  Approval Envelope Schema

     Approval Envelopes have two wire profiles.  An
     ApprovalEnvelopeSubmission is submitted by the orchestrating agent to
     POST /v1/approvals.  A StoredApprovalEnvelope is returned by Registry
     read and mutation endpoints and includes Registry-managed lifecycle
     fields.  A Registry MUST validate POST /v1/approvals request bodies
     against the submission profile and MUST NOT accept read-only stored
     fields in the submission body.

      +============================+==========+=========================+
      | Field                      | Required | Constraints             |
      +============================+==========+=========================+
      | approval_id                | REQUIRED | pattern:                |
      |                            |          | apr:<UUIDv4-lowerhex>   |
      +----------------------------+----------+-------------------------+
      | created_by                 | REQUIRED | AID of orchestrating    |
      |                            |          | agent                   |
      +----------------------------+----------+-------------------------+
      | creator_kid                | REQUIRED | DID URL identifying the |
      |                            |          | Ed25519 verification    |
      |                            |          | method controlled by    |
      |                            |          | created_by              |



  Singla                  Expires 15 November 2026              [Page 127]


  Internet-Draft                     AIP                          May 2026


      +----------------------------+----------+-------------------------+
      | principal_id               | REQUIRED | W3C DID; MUST NOT be    |
      |                            |          | did:aip                 |
      +----------------------------+----------+-------------------------+
      | engagement_id              | OPTIONAL | pattern:                |
      |                            |          | eng:<UUIDv4-lowerhex>;  |
      |                            |          | links to parent         |
      |                            |          | Engagement Object       |
      +----------------------------+----------+-------------------------+
      | description                | REQUIRED | minLength: 1;           |
      |                            |          | maxLength: 512          |
      +----------------------------+----------+-------------------------+
      | created_at                 | REQUIRED | ISO 8601 UTC; set by    |
      |                            |          | orchestrating agent;    |
      |                            |          | MUST NOT be in the      |
      |                            |          | future beyond 30-second |
      |                            |          | clock skew              |
      +----------------------------+----------+-------------------------+
      | approval_window_expires_at | REQUIRED | ISO 8601 UTC; MUST be   |
      |                            |          | strictly after          |
      |                            |          | created_at; MUST NOT be |
      |                            |          | more than 72 hours      |
      |                            |          | after created_at        |
      +----------------------------+----------+-------------------------+
      | steps                      | REQUIRED | minItems: 1; maxItems:  |
      |                            |          | 20                      |
      +----------------------------+----------+-------------------------+
      | compensation_steps         | OPTIONAL | Compensation steps for  |
      |                            |          | SAGA rollback           |
      +----------------------------+----------+-------------------------+
      | total_value                | OPTIONAL | Total financial value;  |
      |                            |          | MUST equal sum of step  |
      |                            |          | values, treating        |
      |                            |          | omitted step values as  |
      |                            |          | 0                       |
      +----------------------------+----------+-------------------------+
      | currency                   | OPTIONAL | ISO 4217; pattern:      |
      |                            |          | ^[A-Z]{3}$              |
      +----------------------------+----------+-------------------------+
      | notification_uri           | OPTIONAL | HTTPS URI for principal |
      |                            |          | notification callbacks; |
      |                            |          | included in creator and |
      |                            |          | principal signing       |
      |                            |          | inputs when present     |
      +----------------------------+----------+-------------------------+
      | creator_signature          | REQUIRED | base64url EdDSA         |
      |                            |          | signature               |
      +----------------------------+----------+-------------------------+



  Singla                  Expires 15 November 2026              [Page 128]


  Internet-Draft                     AIP                          May 2026


                  Table 25: ApprovalEnvelopeSubmission Fields

     An ApprovalEnvelopeSubmission MUST NOT contain top-level status,
     principal_signature, or approved_at.  Its forward steps MUST NOT
     contain read-only status, claimed_at, or completed_at fields.  Its
     compensation steps MUST NOT contain read-only status fields.  If any
     read-only field is present in the submission body, the Registry MUST
     reject with approval_envelope_invalid.

     +===========================+==================+====================+
     |Field                      |     Required     |Constraints         |
     +===========================+==================+====================+
     |status                     |REQUIRED          |Registry-managed    |
     |                           |                  |lifecycle state;    |
     |                           |                  |initially           |
     |                           |                  |pending_approval    |
     +---------------------------+------------------+--------------------+
     |principal_signature        |CONDITIONAL       |Set only by         |
     |                           |                  |successful          |
     |                           |                  |principal approval; |
     |                           |                  |required for        |
     |                           |                  |approved,           |
     |                           |                  |executing,          |
     |                           |                  |completed,          |
     |                           |                  |compensating,       |
     |                           |                  |compensated, and    |
     |                           |                  |failed envelopes    |
     +---------------------------+------------------+--------------------+
     |principal_kid              |CONDITIONAL       |DID URL identifying |
     |                           |                  |the principal       |
     |                           |                  |verification        |
     |                           |                  |method; required    |
     |                           |                  |whenever            |
     |                           |                  |principal_signature |
     |                           |                  |is present          |
     +---------------------------+------------------+--------------------+
     |approved_at                |CONDITIONAL       |Registry timestamp  |
     |                           |                  |set with the        |
     |                           |                  |winning approval    |
     |                           |                  |transition;         |
     |                           |                  |required whenever   |
     |                           |                  |principal_signature |
     |                           |                  |is present          |
     +---------------------------+------------------+--------------------+
     |steps[].status             |REQUIRED          |Registry-managed    |
     |                           |                  |step lifecycle      |
     |                           |                  |state; initially    |
     |                           |                  |pending             |



  Singla                  Expires 15 November 2026              [Page 129]


  Internet-Draft                     AIP                          May 2026


     +---------------------------+------------------+--------------------+
     |steps[].claimed_at         |CONDITIONAL       |Registry timestamp  |
     |                           |                  |set when a Step     |
     |                           |                  |Execution Token is  |
     |                           |                  |issued              |
     +---------------------------+------------------+--------------------+
     |steps[].completed_at       |CONDITIONAL       |Registry timestamp  |
     |                           |                  |set when a forward  |
     |                           |                  |step completes      |
     +---------------------------+------------------+--------------------+
     |compensation_steps[].status|REQUIRED when     |Registry-managed    |
     |                           |compensation_steps|compensation        |
     |                           |is present        |lifecycle state;    |
     |                           |                  |initially pending   |
     +---------------------------+------------------+--------------------+

                Table 26: StoredApprovalEnvelope Registry Fields

     total_value and currency MUST both be present or both absent.  When
     present, total_value MUST equal the sum of value fields across ALL
     steps.  A step that omits value contributes 0 to this sum.  Required
     and optional steps are both included in the sum when they carry a
     value field.  This value is the maximum approved financial exposure
     of the envelope, not a prediction that every optional step will
     execute.

     When present, engagement_id scopes the Approval Envelope to the
     parent Engagement Object.  The field is part of the Approval Envelope
     body and MUST NOT be supplied only as external Registry metadata.
     Both creator_signature and principal_signature signing inputs MUST
     include engagement_id whenever it is present.

     The creator_signature signing input is the Section 2.1 canonical JSON
     serialization of the ApprovalEnvelopeSubmission object with
     creator_signature set to "".  The principal_signature signing input
     is the same immutable submission object after successful submission,
     including creator_signature, principal_kid, and a principal_signature
     member set to "".  Both signing inputs include creator_kid,
     notification_uri, and engagement_id when present.  The DID portion of
     creator_kid MUST equal created_by; the DID portion of principal_kid
     MUST equal principal_id.  Neither signing input includes Registry-
     managed top-level lifecycle fields (status or approved_at) or
     Registry-managed step fields (status, claimed_at, or completed_at).

  13.4.  Step Schema

     Each element in the steps array represents one atomic action at one
     Relying Party.



  Singla                  Expires 15 November 2026              [Page 130]


  Internet-Draft                     AIP                          May 2026


     +====================+===========+=================================+
     | Field              |  Required | Constraints                     |
     +====================+===========+=================================+
     | step_index         | REQUIRED  | 1-based; unique within envelope |
     +--------------------+-----------+---------------------------------+
     | actor              | REQUIRED  | AID executing this step         |
     +--------------------+-----------+---------------------------------+
     | relying_party_uri  | REQUIRED  | URI of the Relying Party        |
     +--------------------+-----------+---------------------------------+
     | action_type        | REQUIRED  | Application-defined; maxLength: |
     |                    |           | 128                             |
     +--------------------+-----------+---------------------------------+
     | action_hash        | REQUIRED  | sha256:64-hex; see Section 13.7 |
     +--------------------+-----------+---------------------------------+
     | scopes             | REQUIRED  | minItems: 1; uniqueItems: true; |
     |                    |           | each item is an AIP scope       |
     |                    |           | string required for this step   |
     +--------------------+-----------+---------------------------------+
     | description        | REQUIRED  | minLength: 1; maxLength: 256    |
     +--------------------+-----------+---------------------------------+
     | required           | REQUIRED  | boolean; false = optional step  |
     +--------------------+-----------+---------------------------------+
     | triggered_by       | REQUIRED  | null or step_index; 0 forbidden |
     +--------------------+-----------+---------------------------------+
     | compensation_index | OPTIONAL  | 1-based pointer to a            |
     |                    |           | compensation step; null or      |
     |                    |           | absent means no compensation    |
     |                    |           | action is defined               |
     +--------------------+-----------+---------------------------------+
     | value              | OPTIONAL  | Financial value; minimum: 0;    |
     |                    |           | omitted means 0 for total_value |
     |                    |           | validation                      |
     +--------------------+-----------+---------------------------------+
     | currency           | OPTIONAL  | ISO 4217 currency code for this |
     |                    |           | step's value; when present,     |
     |                    |           | MUST match envelope currency    |
     +--------------------+-----------+---------------------------------+
     | status             | READ-ONLY | pending | claimed | completed | |
     |                    |           | failed | compensated |          |
     |                    |           | skipped | cancelled             |
     +--------------------+-----------+---------------------------------+

                            Table 27: Step Fields

     The triggered_by field implements the SAGA DAG.  A step with
     triggered_by: null is a root step.  A step with triggered_by: N MUST
     NOT be claimed before step N reaches completed status.  Circular
     dependencies MUST be rejected.



  Singla                  Expires 15 November 2026              [Page 131]


  Internet-Draft                     AIP                          May 2026


     Multiple steps MAY share the same triggered_by value, enabling
     parallel execution paths.

     The compensation_index field, when present on a forward step,
     identifies the single compensation step that rolls back that forward
     step.  The value is a 1-based identifier that MUST equal the
     compensation_index field of exactly one entry in compensation_steps;
     it is not a zero-based JSON array offset.  The Registry MUST reject
     envelopes where a non-null compensation_index does not reference an
     existing compensation step, or where more than one forward step
     references the same compensation step.

  13.5.  Compensation Step Schema

     Compensation steps define SAGA rollback actions pre-authorised by the
     principal.  If a forward step fails, compensation actions execute
     without requiring new human approval.

     A compensation step is selected only through a forward step's
     compensation_index field.  The Registry MUST NOT infer a compensation
     relationship from matching action_type values, array position, actor
     identity, or relying party URI.





























  Singla                  Expires 15 November 2026              [Page 132]


  Internet-Draft                     AIP                          May 2026


         +====================+==========+===========================+
         | Field              | Required | Constraints               |
         +====================+==========+===========================+
         | compensation_index | REQUIRED | 1-based; unique within    |
         |                    |          | compensation_steps        |
         +--------------------+----------+---------------------------+
         | actor              | REQUIRED | AID executing             |
         |                    |          | compensation              |
         +--------------------+----------+---------------------------+
         | relying_party_uri  | REQUIRED | URI of the Relying Party  |
         +--------------------+----------+---------------------------+
         | action_type        | REQUIRED | Application-defined       |
         |                    |          | rollback                  |
         +--------------------+----------+---------------------------+
         | action_hash        | REQUIRED | sha256:64-hex             |
         +--------------------+----------+---------------------------+
         | scopes             | REQUIRED | minItems: 1; uniqueItems: |
         |                    |          | true; each item is an AIP |
         |                    |          | scope string required for |
         |                    |          | this compensation step    |
         +--------------------+----------+---------------------------+
         | description        | REQUIRED | Plain-language rollback   |
         |                    |          | description               |
         +--------------------+----------+---------------------------+

                       Table 28: Compensation Step Fields

  13.6.  Approval Envelope Lifecycle

     The Registry maintains lifecycle state with valid transitions:

                pending_approval --> approved --> executing --> completed
                    |                |             |
                    v                v             v
                rejected          expired     compensating --> compensated
                                                   |
                                                   v
                                                 failed

                pending_approval --> cancelled
                approved         --> cancelled
                executing        --> cancelled

     *Transition rules:*







  Singla                  Expires 15 November 2026              [Page 133]


  Internet-Draft                     AIP                          May 2026


     pending_approval to approved
        Principal signs via Principal Wallet.  Registry atomically stores
        principal_signature, sets approved_at, and transitions the
        envelope to approved.  Only envelopes currently in
        pending_approval can make this transition.

     pending_approval to rejected
        Principal declines.

     pending_approval to expired
        approval_window_expires_at passes before a successful approval
        transition is committed.

     approved to executing
        First step is claimed.  Automatic transition.

     executing to completed
        All required: true steps reach completed status.

     executing to compensating
        Any required: true step fails with compensation_index present.

     compensating to compensated
        All compensation steps complete successfully.

     compensating to failed
        One or more compensation steps fail.  Terminal state.

     pending_approval, approved, or executing to cancelled
        Parent Engagement Object transitions to terminated.  The Registry
        MUST NOT transition Approval Envelopes to cancelled solely because
        the parent Engagement Object transitions to completed.

     The approval_window_expires_at field is an approval-deadline only.
     It controls whether an envelope is eligible to transition from
     pending_approval to approved.  Once an envelope has transitioned to
     approved before that deadline, later passage of
     approval_window_expires_at MUST NOT transition the envelope to
     expired and MUST NOT be used to reject step claims.  Execution time
     limits, if any, MUST be expressed by a separate field or by endpoint
     policy; they MUST NOT be inferred from approval_window_expires_at.

     Terminal states (no further transitions): completed, compensated,
     failed, rejected, expired, cancelled.

     The Registry MUST treat approval, rejection, expiry, cancellation,
     and first step claim as mutually exclusive state transitions over the
     same Approval Envelope lifecycle record.  Implementations MUST use



  Singla                  Expires 15 November 2026              [Page 134]


  Internet-Draft                     AIP                          May 2026


     optimistic locking, compare-and-set, a database transaction, or an
     equivalent distributed lock so that exactly one concurrent transition
     out of pending_approval can succeed.  If multiple Principal Wallets
     submit valid approval signatures concurrently for the same
     principal_id, the first committed approval wins.  The Registry MUST
     NOT replace principal_signature, approved_at, or the winning state
     with a later approval request.  A later approval or rejection request
     that races with or follows a completed lifecycle transition MUST fail
     with approval_state_conflict, except that an exact byte-for-byte
     retry of the already stored approval response MAY be treated as
     idempotent and return the stored envelope.

     When an envelope transitions to cancelled, pending forward steps
     under that envelope MUST transition directly to cancelled.  Claimed
     forward steps MUST be treated as failed for compensation-trigger
     evaluation, then MUST transition to cancelled after any required
     compensation resolution completes or fails.  Completed, failed,
     compensated, and skipped steps retain their existing status for audit
     purposes.  The Registry MUST NOT issue new Step Execution Tokens for
     cancelled envelopes or cancelled steps.

  13.7.  Action Hash Computation

     The action_hash binds the principal's approval to the specific
     content of the action.  An agent MUST NOT execute a different action
     than the principal approved.

     The action_hash is computed as:

     action_hash = "sha256:"
       + LCHEX( SHA-256( JCS( action_parameters ) ) )

     Where action_parameters contains:

     *  approval_id - The approval_id of the envelope

     *  step_index - The step_index of this step

     *  actor - The actor AID

     *  relying_party_uri - The Relying Party URI

     *  action_type - The action type

     *  parameters - Application-defined JSON object

     Implementations MUST use an RFC8785-conformant library.  Financial
     amounts MUST be represented as JSON numbers (not strings).



  Singla                  Expires 15 November 2026              [Page 135]


  Internet-Draft                     AIP                          May 2026


  13.8.  Step Claim and Execution Protocol

     To execute a step, an agent follows this protocol:

     *Step 1 - Claim:* The agent calls POST /v1/
     approvals/{id}/steps/{n}/claim with a valid Credential Token and
     action_parameters.

     The Registry MUST atomically verify all of the following:

     1.  Envelope status is approved or executing

     2.  Step status is pending

     3.  All triggered_by steps are completed

     4.  Token iss matches step actor

     5.  Credential Token passes validation

     6.  Credential Token aip_scope contains every scope listed in the
         step's scopes array

     7.  action_hash matches stored value

     The Registry MUST NOT evaluate approval_window_expires_at as a step-
     claim condition for an envelope already in approved or executing
     status.

     If the triggered_by check fails because one or more prerequisite
     steps have not reached "completed", the Registry MUST reject the
     claim with approval_step_prerequisites_unmet and MUST NOT issue a
     Step Execution Token.

     If all checks pass, the Registry returns a Step Execution Token
     signed by a JWK listed in active_verification_keys.step_execution of
     the Registry Trust Record version current at issuance time:














  Singla                  Expires 15 November 2026              [Page 136]


  Internet-Draft                     AIP                          May 2026


     header = {
       "typ": "AIP-SET+JWT",
       "alg": "EdDSA",
       "kid": "<Registry step-execution keyid>",
       "aip_trv": <Registry Trust Record version>
     }

     payload = {
       "iss": "<Registry ID>",
       "sub": "<actor AID>",
       "aud": "<relying_party_uri>",
       "iat": <now>,
       "exp": <now + 300>,
       "jti": "<UUID>",
       "aip_version": "0.3",
       "aip_scope": ["transactions"],
       "aip_chain": ["<compact Principal Token JWT>"],
       "aip_approval_id": "<approval_id>",
       "aip_step_kind": "forward",
       "aip_approval_step": <step_index>
     }

     A Step Execution Token is not an agent-issued Credential Token.  Its
     iss is the Registry ID HTTPS URI, its sub is the claimed step actor
     AID, and its JOSE kid identifies a step-execution verification key
     from the Registry Trust Record.  Relying Parties MUST validate Step
     Execution Tokens using the SET validation profile in Section 9 before
     applying Step 10a.  The Registry MUST derive the SET aip_scope value
     from the claimed step's scopes array and MUST derive the SET exp
     value using the TTL rule in Section 5.4.1.

     *Step 2 - Execute:* The agent presents the Step Execution Token to
     the Relying Party.

     *Step 3 - Complete or Fail:* After execution, the agent MUST call
     /complete or /fail before the claim deadline.  The claim deadline is
     claimed_at + step_claim_timeout_seconds, where
     step_claim_timeout_seconds is the Registry policy value published in
     /v1/registry-metadata.  The value MUST be an integer from 1 to 600
     seconds inclusive.

     If a claimed step is not completed or failed before that deadline,
     the Registry MUST treat the claim as timed out, transition the step
     to failed, and apply the SAGA compensation rules as if the actor had
     explicitly reported step failure.






  Singla                  Expires 15 November 2026              [Page 137]


  Internet-Draft                     AIP                          May 2026


     The JSON body profiles for claim, complete, and fail requests and
     responses are defined in approval-step-endpoints.schema.json.  All
     request bodies in this section MUST use Content-Type: application/
     json.  The Registry MUST ignore any client-supplied completion or
     failure timestamp for lifecycle purposes; claimed_at, completed_at,
     and failure timestamps are Registry receipt times.

     *Claim request:* A forward step claim request body MUST conform to
     the claim_request profile and contain credential_token and
     action_parameters.  The Registry MUST validate the Credential Token
     using Section 9 with the Registry claim endpoint as the Relying
     Party.  The token issuer, token subject, and leaf Principal Token
     subject MUST equal the step actor.  The Registry MUST recompute the
     step action_hash from action_parameters using Section 13.7 and MUST
     reject a mismatch with approval_step_action_mismatch.  The Credential
     Token aip_scope set MUST contain every scope in the claimed step's
     scopes array; otherwise the Registry MUST reject with
     insufficient_scope.

     On a successful forward claim, the Registry MUST atomically
     transition the forward step from pending to claimed, set claimed_at,
     store the issued SET jti, transition the envelope from approved to
     executing if this is the first claimed step, and return a
     claim_response containing the compact Step Execution Token.  If the
     same actor repeats the same claim request with the same
     idempotency_key before the claim expires, the Registry MAY return the
     stored claim response.  A different actor, different request body,
     expired claim, or missing matching idempotency record MUST NOT be
     treated as an idempotent retry.

     *Complete request:* A complete request body MUST conform to the
     complete_request profile and contain step_execution_token.  The
     Registry MUST validate the SET using the Section 9 SET validation
     profile, verify that the SET aip_approval_id and step identifier
     match the request path, verify that the SET sub equals the step
     actor, verify that the SET jti equals the stored jti for the active
     claim, and verify that the step or compensation step is currently
     claimed and has not passed its claim deadline.  If any of these
     checks fail, the Registry MUST reject with approval_step_invalid or
     approval_step_not_claimed as applicable.











  Singla                  Expires 15 November 2026              [Page 138]


  Internet-Draft                     AIP                          May 2026


     On a successful forward-step complete request, the Registry MUST
     transition the step to completed, set completed_at, persist any
     supplied result_hash or evidence_uri as audit metadata, and evaluate
     envelope completion.  If all required forward steps are completed and
     no compensation is pending, the Registry MUST transition the envelope
     to completed.  Exact retries with the same idempotency_key MAY return
     the stored complete_response; conflicting repeats MUST reject with
     approval_state_conflict.

     *Fail request:* A fail request body MUST conform to the fail_request
     profile and contain step_execution_token and failure_code.  The
     Registry MUST perform the same SET, actor, path, stored-jti, state,
     and deadline checks required for completion.  On success, the
     Registry MUST transition the step to failed, persist the supplied
     failure metadata for audit, and apply the SAGA compensation rules.
     Exact retries with the same idempotency_key MAY return the stored
     fail_response; conflicting repeats MUST reject with
     approval_state_conflict.

     *Compensation endpoints:* POST /v1/approvals/{id}/compensation-
     steps/{n}/claim, /complete, and /fail use the same request and
     response profiles as forward-step endpoints.  The path {n} is the
     compensation step's compensation_index.  Compensation claims are
     valid only when the envelope is compensating and the compensation
     step has been triggered by the SAGA rules in Section 13.9.  SETs
     issued for compensation claims MUST contain aip_step_kind:
     "compensation" and aip_compensation_step, and MUST NOT contain
     aip_approval_step.

  13.9.  SAGA Compensation Semantics

     When any required: true step fails after one or more earlier steps
     completed, the Registry MUST:

     1.  Transition envelope status to compensating

     2.  Build the compensation set from forward steps whose status is
         completed and whose compensation_index is non-null.  The failed
         forward step is included in this set only if its status had
         previously reached completed before the failure was reported.

     3.  Sort that forward-step set by descending step_index.

     4.  For each sorted forward step, trigger the compensation step
         referenced by that forward step's compensation_index.

     5.  Notify the orchestrating agent




  Singla                  Expires 15 November 2026              [Page 139]


  Internet-Draft                     AIP                          May 2026


     Compensation steps that are not referenced by any completed forward
     step MUST NOT be triggered.  If the failed required step has no
     completed side effects and no completed predecessor has a non-null
     compensation_index, the Registry MUST transition the envelope
     directly to failed rather than compensating.  If a completed forward
     step references a compensation step that cannot be found, the
     envelope is invalid and the Registry MUST treat the compensation
     attempt as failed.

     Rollback ordering is based on the forward steps' descending
     step_index values, not on compensation_index order.  The
     compensation_index value is used only to dereference the pre-
     authorised compensation step selected for each completed forward
     step.

     Because the principal pre-approved all compensation steps, no
     additional human interaction is required.  This is the core SAGA
     property.

     If a compensation step itself fails, the envelope transitions to
     failed (terminal).  The Registry MUST set the failed compensation
     step status to failed, set the envelope status to failed, persist an
     audit record containing the approval ID, compensation index, actor
     AID, failure timestamp, and failure reason, and return or expose
     compensation_failed for the failed transition.

     The Registry MUST create a principal notification event for the
     terminal compensation failure.  If the Approval Envelope contains a
     notification_uri, the Registry MUST attempt delivery to that URI.  If
     RPNP is supported and a matching active subscription exists, the
     Registry MUST also emit an RPNP event.  If no delivery channel is
     configured, the Registry MUST retain the notification event and
     expose it in the Approval Envelope status response until acknowledged
     by local policy.  Human remediation of the failed business action
     remains outside AIP, but the failure state, audit record, and
     notification event are AIP protocol obligations.

  13.10.  Approval Envelope Validation Rules

     The Registry MUST reject an Approval Envelope at submission time if
     any of the following are true:

     1.   principal_id begins with the exact ASCII prefix did:aip:; reject
          with approval_envelope_invalid.  This is a byte-for-byte prefix
          comparison against the first eight characters of the string;
          values whose first eight characters are did:aip: identify an
          agent AID and are not valid principal identifiers.




  Singla                  Expires 15 November 2026              [Page 140]


  Internet-Draft                     AIP                          May 2026


     2.   engagement_id is present but malformed: reject with
          approval_envelope_invalid.  If engagement_id references an
          Engagement Object that does not exist, reject with
          engagement_not_found.

     3.   steps contains circular dependencies in triggered_by: reject
          with approval_envelope_invalid.

     4.   steps contains duplicate step_index values: reject with
          approval_envelope_invalid.

     5.   total_value != sum of step values, treating omitted step value
          fields as 0: reject with approval_envelope_invalid.

     6.   Any present step currency differs from the envelope currency:
          reject with approval_envelope_invalid.

     7.   approval_window_expires_at is in the past: reject with
          approval_envelope_expired.

     8.   created_at is in the future beyond 30-second clock skew: reject
          with approval_envelope_invalid.

     9.   approval_window_expires_at is not strictly after created_at, or
          is more than 72 hours after created_at: reject with
          approval_envelope_invalid.

     10.  compensation_index references a non-existent index: reject with
          approval_envelope_invalid.

     11.  compensation_steps contains duplicate compensation_index values
          or values that are not sequential starting at 1: reject with
          approval_envelope_invalid.

     12.  More than one forward step references the same non-null
          compensation_index: reject with approval_envelope_invalid.

     13.  creator_signature does not verify: reject with
          approval_envelope_invalid.

     14.  created_by agent is revoked: reject with agent_revoked.

     15.  steps contains more than 20 elements: reject with
          approval_envelope_invalid.







  Singla                  Expires 15 November 2026              [Page 141]


  Internet-Draft                     AIP                          May 2026


     16.  triggered_by is 0: reject with approval_envelope_invalid.  An
          absent triggered_by field is a schema violation because the
          field is REQUIRED by the step schema and is rejected before this
          semantic validation rule is evaluated.

     17.  A forward or compensation step omits scopes, includes an empty
          scopes array, includes duplicate scope strings, or includes a
          scope that is not active in the synced AIP Scope Catalog: reject
          with approval_envelope_invalid.

     The Registry MUST also reject envelopes with insufficient_scope
     unless the submitting orchestrating agent's Credential Token and
     current Capability Manifest both include the active approvals.create
     scope from the synced AIP Scope Catalog.  Transaction, communication,
     filesystem, and agent-spawning scopes alone do not grant authority to
     submit Approval Envelopes.

     *Rule DESTRUCTIVE-1 (Mandatory Approval):* Any operation involving a
     scope whose active AIP Scope Catalog entry has destructive: true MUST
     be authorised via a dedicated Approval Envelope step or a direct
     human confirmation ceremony.  Registry-mediated G1 grants MUST NOT be
     used for destructive operations without an additional out-of-band
     confirmation.

  14.  Reputation and Endorsements

  14.1.  Endorsement Object

     Any Relying Party or agent MAY submit a signed Endorsement Object to
     the Registry after a completed interaction.  The schema is in
     Section 5.8.

     The Registry MUST verify every submitted Endorsement Object
     signature.  Only success and partial outcomes increment
     endorsement_count. failure increments incident_count.

     The optional Endorsement Object notes field is signed audit context
     only.  It MUST NOT be used as an input to reputation scoring,
     endorsement weighting, validation, or counter updates.












  Singla                  Expires 15 November 2026              [Page 142]


  Internet-Draft                     AIP                          May 2026


     Completed Approval Envelope steps SHOULD generate Endorsement
     Objects.  When an Approval Envelope reaches completed status, the
     orchestrator SHOULD submit an Endorsement Object for each agent that
     executed a step successfully.  This is a reputation-input
     recommendation, not a protocol validation gate.  Registries and
     Relying Parties cannot prove that an orchestrator failed to submit an
     expected Endorsement Object, and absence of such an endorsement MUST
     NOT cause Approval Envelope validation, Credential Token validation,
     or step-completion processing to fail.

  14.1.1.  Endorsement Acceptance Requirements

     A conformant Registry that accepts endorsements, by implementing POST
     /v1/endorsements, MUST enforce the following minimum acceptance rules
     regardless of its reputation scoring algorithm:

     1  The endorsement signature MUST be verified using signature_kid.
        The DID portion of signature_kid MUST equal from_aid, and the key
        MUST be Ed25519 verification material controlled by that AID.  If
        key binding or signature verification fails, the Registry MUST
        reject with endorsement_invalid.

     2  The from_aid MUST be a registered, non-revoked agent AID in the
        Registry.  If not, the Registry MUST reject with unknown_aid or
        agent_revoked.

     3  The to_aid MUST be a registered agent AID in the Registry.  If
        not, the Registry MUST reject with unknown_aid.

     4  The score field MUST be in the range 1 through 5 inclusive, as an
        integer or decimal value.  Values outside this range MUST be
        rejected with endorsement_invalid.

  14.2.  Reputation Scoring

     Reputation scoring algorithms, aggregation functions, and score decay
     policies are implementation-defined and are not subject to
     conformance testing.  A Registry that implements the Reputation
     Output optional feature MUST expose a reputation score in the range
     0.0 through 5.0 at GET /v1/agents/{aid}/reputation in a response
     containing at minimum:

     *  score: number, current reputation score in the range 0.0 through
        5.0;

     *  endorsement_count: integer, total number of accepted endorsements;





  Singla                  Expires 15 November 2026              [Page 143]


  Internet-Draft                     AIP                          May 2026


     *  computed_at: string, ISO 8601 UTC timestamp of last score
        computation.

     A Registry that implements this optional feature MUST expose
     reputation data for every registered AID at GET /v1/
     agents/{aid}/reputation.  Required fields: registration_date,
     task_count, successful_task_count, endorsement_count, incident_count,
     revocation_history, last_active.

     The aggregate reputation counters are single-resource fields and are
     not paginated.  The revocation_history member is a collection and
     MUST use the cursor pagination rules in Section 17.20.  A response
     MUST include no more than the effective limit revocation history
     entries and MUST include a pagination object for continuing the
     history scan.  Absence of older history on the current page MUST NOT
     be interpreted as absence of older revocations when
     pagination.has_more is true.

     The Registry MAY expose a reference advisory score labelled
     advisory_only: true.  Relying Parties MUST NOT treat it as normative.
     AIP standardises reputation inputs, not the scoring formula.

     Reputation Non-Transferability: Reputation is bound to a specific
     AID.  Implementations MUST NOT transfer reputation from revoked to
     new AIDs.  Endorsements from AIDs with current full_revoke or
     principal_revoke status MUST NOT be weighted.

  15.  Lifecycle States

     An AID has exactly two lifecycle states: active and revoked.  AIP
     does not define an inactive status; the Dead Man's Switch mechanism
     (Section 21.8) uses full_revoke.

     An AID MUST remain valid until explicitly revoked.  Revoked AIDs MUST
     NOT be reused.  Key rotation preserves the AID but changes the active
     key.  Outstanding tokens signed under the previous key remain valid
     until their exp, unless the AID or token is otherwise revoked.
     Registries MUST retain retired public verification keys for at least
     the maximum Credential Token TTL plus clock skew after the key's
     valid_until time, so that conforming unexpired tokens remain
     verifiable.  Relying Parties MUST perform the expiration preflight in
     Section 9 before historical key lookup so expired tokens return
     token_expired even after retired key material is no longer retained.

     Agents whose synced AIP Namespace Catalog entry has requires_task_id:
     true MUST have a non-null task_id.  Namespace-specific lifecycle
     rules, including task-completion revocation expectations, are defined
     by the AIP Namespace Catalog.  For the Draft-02 catalog, ephemeral



  Singla                  Expires 15 November 2026              [Page 144]


  Internet-Draft                     AIP                          May 2026


     agents MUST be explicitly revoked on task completion.  The Registry
     MUST also persist a lifecycle_expires_at deadline for each ephemeral
     agent at registration time.  This deadline MUST be no later than the
     earlier of the decoded root Principal Token expires_at value and the
     initial Capability Manifest expires_at value.  The Registry MUST
     automatically issue or materialise a full_revoke Revocation Object
     for the ephemeral AID with reason lifecycle_expired no later than 15
     seconds after lifecycle_expires_at passes if the AID has not already
     been revoked.  This auto-revocation requirement is a Registry
     conformance requirement; Relying Parties MUST still perform normal
     Principal Token, Capability Manifest, and revocation validation and
     MUST NOT rely on auto-revocation as the only expiry check.

  16.  Principal Chain

     The principal chain is the sequence of delegation relationships that
     connects a root human or organisational principal, identified by a
     W3C DID, to a leaf agent, identified by a did:aip AID.  Each link in
     the chain is represented by a Principal Token (Section 5.5).  The
     chain is embedded in Credential Tokens and Step Execution Tokens as
     the aip_chain array.

     Normative rules governing the principal chain are defined as follows:

     *  Chain structure and depth rules: Section 10.1.

     *  Capability scope inheritance across the chain: Section 10.2.

     *  Chain validation algorithm: Section 9.11 Steps 8a through 8l and
        Post-Checks A, B, and C.

     *  Grant ceremony that establishes the first chain link: Section 12.

     *  A2A identity chaining for multi-agent chains: Section 10.4.

     This section serves as the normative index for the principal chain
     concept.  Implementations MUST consult the sections above for all
     chain-related requirements.

  17.  Registry Interface

     A conformant AIP Registry MUST implement the unconditional HTTP
     endpoints in this section and MUST implement each feature-conditional
     endpoint set for any feature, grant tier, or publication mode it
     advertises or enables.






  Singla                  Expires 15 November 2026              [Page 145]


  Internet-Draft                     AIP                          May 2026


  17.1.  Endpoint Inventory

     A conformant AIP Registry MUST implement the following unconditional
     HTTP endpoints:

     +========+===================================+=====================+
     | Method | Path                              | Description         |
     +========+===================================+=====================+
     | POST   | /v1/agents                        | Register a new AID  |
     |        |                                   | (Registration       |
     |        |                                   | Envelope)           |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/agents/{aid}                  | Retrieve Agent      |
     |        |                                   | Registration        |
     |        |                                   | Metadata or DID     |
     |        |                                   | Document            |
     +--------+-----------------------------------+---------------------+
     | PUT    | /v1/agents/{aid}                  | Key rotation only   |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/agents/{aid}/public-key       | Current public key  |
     |        |                                   | (JWK)               |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/agents/{aid}/public-key/{key- | Historical key      |
     |        | id}                               | version             |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/agents/{aid}/capabilities     | Current Capability  |
     |        |                                   | Manifest            |
     +--------+-----------------------------------+---------------------+
     | PUT    | /v1/agents/{aid}/capabilities     | Replace Capability  |
     |        |                                   | Manifest            |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/agents/{aid}/heartbeat        | Submit signed agent |
     |        |                                   | heartbeat           |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/agents/{aid}/revocation       | Revocation status   |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/revocations                   | Submit              |
     |        |                                   | RevocationObject    |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/crl                           | Origin AIP CRL      |
     |        |                                   | document; preferred |
     |        |                                   | CRL retrieval URI   |
     |        |                                   | is published as     |
     |        |                                   | endpoints.crl       |
     +--------+-----------------------------------+---------------------+
     | PUT    | /v1/agents/{aid}/overlays         | Submit Capability   |
     |        |                                   | Overlay             |
     +--------+-----------------------------------+---------------------+



  Singla                  Expires 15 November 2026              [Page 146]


  Internet-Draft                     AIP                          May 2026


     | GET    | /v1/agents/{aid}/overlays         | Retrieve current    |
     |        |                                   | overlay             |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/scopes                        | Synced AIP Scope    |
     |        |                                   | Catalog metadata    |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/namespaces                    | Synced AIP          |
     |        |                                   | Namespace Catalog   |
     |        |                                   | metadata            |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/registry-metadata             | Retrieve Registry   |
     |        |                                   | Metadata            |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/registry-trust/current        | Retrieve current    |
     |        |                                   | Registry Trust      |
     |        |                                   | Record              |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/registry-trust/{version}      | Retrieve immutable  |
     |        |                                   | Registry Trust      |
     |        |                                   | Record by version   |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals                     | Submit Approval     |
     |        |                                   | Envelope for        |
     |        |                                   | approval            |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/approvals/{id}                | Retrieve Approval   |
     |        |                                   | Envelope with step  |
     |        |                                   | statuses            |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/approve        | Principal approves  |
     |        |                                   | Approval Envelope   |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/reject         | Principal rejects   |
     |        |                                   | Approval Envelope   |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/                              | Claim step for      |
     |        | approvals/{id}/steps/{n}/claim    | execution           |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/                              | Mark step completed |
     |        | approvals/{id}/steps/{n}/complete |                     |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/steps/{n}/fail | Mark step failed    |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/approvals/{id}/steps/{n}      | Retrieve step       |
     |        |                                   | status for SET      |
     |        |                                   | verification        |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/compensation-  | Claim compensation  |



  Singla                  Expires 15 November 2026              [Page 147]


  Internet-Draft                     AIP                          May 2026


     |        | steps/{n}/claim                   | step                |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/compensation-  | Mark compensation   |
     |        | steps/{n}/complete                | step completed      |
     +--------+-----------------------------------+---------------------+
     | POST   | /v1/approvals/{id}/compensation-  | Mark compensation   |
     |        | steps/{n}/fail                    | step failed         |
     +--------+-----------------------------------+---------------------+
     | GET    | /v1/approvals/{id}/compensation-  | Retrieve            |
     |        | steps/{n}                         | compensation step   |
     |        |                                   | status for SET      |
     |        |                                   | verification        |
     +--------+-----------------------------------+---------------------+

                  Table 29: Unconditional Registry Endpoints

     The following endpoint sets are feature-conditional.  A Registry MUST
     implement every endpoint in the applicable set when it advertises or
     enables the corresponding feature.  A Registry MUST NOT advertise a
     feature in /v1/registry-metadata, the Registry Trust Record, or other
     discovery metadata unless it implements the complete endpoint set for
     that feature.

     Segmented CRL publication  GET /v1/crl/segments/{segment_id}
        retrieves a signed CRL segment.

     grant_tiers_supported includes G1  POST /v1/grants submits a G1
        grant, and GET /v1/grants/{grant_id} retrieves G1 grant status.

     grant_tiers_supported includes G3  POST /v1/oauth/authorize is the G3
        authorization endpoint.

     G3 or token exchange supported  POST /v1/oauth/token is the G3 token
        endpoint and token exchange endpoint, and GET /.well-known/oauth-
        authorization-server returns AS metadata per [RFC8414].
        Registries that support token exchange MUST also implement POST
        /v1/resources, GET /v1/resources/{resource_id}, PUT /v1/
        resources/{resource_id}, and DELETE /v1/resources/{resource_id} as
        defined in Section 17.13.

     Engagement Objects supported  POST /v1/engagements creates an
        Engagement Object, GET /v1/engagements/{id} retrieves it, POST
        /v1/engagements/{id}/countersign countersigns a proposed
        Engagement Object, and PUT /v1/engagements/{id} appends an
        Engagement change-log update.

     RPNP supported  POST /v1/subscriptions creates an RPNP subscription,




  Singla                  Expires 15 November 2026              [Page 148]


  Internet-Draft                     AIP                          May 2026


        GET /v1/subscriptions/{id} retrieves subscription status, and
        DELETE /v1/subscriptions/{id} cancels the subscription.

     Reputation Output supported  GET /v1/agents/{aid}/reputation returns
        advisory reputation data with the response invariants in
        Section 14.2.  A Registry that does not implement this feature
        MUST return HTTP 501 Not Implemented for this endpoint.

     Endorsement Acceptance supported  POST /v1/endorsements submits an
        Endorsement Object and applies the acceptance rules in
        Section 14.1.1.  A Registry that does not implement this feature
        MUST return HTTP 501 Not Implemented for this endpoint.

  17.2.  AID URL Encoding

     In all path parameters, the did:aip: prefix and colons MUST be
     percent-encoded per [RFC3986]:

     did:aip:personal:9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3
     → /v1/agents/did%3Aaip%3Apersonal%3A9f3a1c82b4e6d7f0a2b5c8e1d4f7a0b3

  17.3.  Response Format

     All Registry responses MUST use Content-Type: application/json,
     except DID Document responses negotiated by Accept: application/
     did+json or Accept: application/did+ld+json from GET /v1/
     agents/{aid}, and CRL responses from GET /v1/crl or the signed
     endpoints.crl URI, which MUST use Content-Type: application/aip-
     crl+json.

     All Registry responses from AIP protocol endpoints MUST include X-
     AIP-Version as defined in Section 8.1.  If a request version is
     unsupported, the Registry MUST reject the request with
     unsupported_version and include X-AIP-Version in the error response.

     Unless an endpoint profile explicitly requires OAuth-native error
     syntax, every Registry error response from an AIP protocol endpoint
     MUST conform to error-response.schema.json and the error response
     rules in Section 18.1.

     All timestamps MUST be in ISO 8601 UTC format.










  Singla                  Expires 15 November 2026              [Page 149]


  Internet-Draft                     AIP                          May 2026


  17.4.  Agent Registration Metadata

     Unless the client sends Accept: application/did+json or Accept:
     application/did+ld+json, GET /v1/agents/{aid} MUST return Content-
     Type: application/json with an Agent Registration Metadata response
     conforming to agent-registration.schema.json.  If the AID is not
     registered, the Registry MUST return unknown_aid.

     The response MUST include the requested aid, the current Agent
     Identity Object as identity, the grant_tier accepted during
     Registration Envelope validation, registered_at, updated_at, and
     links for the current public key, current Capability Manifest, live
     revocation status, and the registration_warnings array.  The identity
     field MUST be the current stored Agent Identity Object at the time of
     the most recent successful registration or key rotation, and
     identity.aid MUST equal the top-level aid.  The registration_warnings
     array MAY be empty.  If Registration Check 15 accepted a Tier 2
     registration without identity.model.attestation_hash, the array MUST
     include the persisted model_attestation_missing_tier2 warning until
     the registered Agent Identity Object includes a valid attestation
     hash.

     A successful POST /v1/agents response MUST use HTTP 201 and MUST
     return the same Agent Registration Metadata representation that a
     subsequent GET /v1/agents/{aid} request would return.  Any
     registration warning created during validation MUST therefore be
     visible in the registration response and in later metadata reads.

     Relying Parties use the registered grant_tier value for each
     participating aip_chain AID during Step 9d Grant Tier Conformance
     validation.

  17.5.  Agent Key Rotation Endpoint

     PUT /v1/agents/{aid} is used only for key rotation of an existing
     AID.  The request body MUST be a complete Agent Identity Object, not
     a Registration Envelope.  The request MUST use Content-Type:
     application/json and MUST include a DPoP proof for the exact PUT
     request URI.  For an ordinary rotation, the DPoP proof MUST verify
     against the current active public key for the AID before the rotation
     is committed.  If the path {aid} is not already registered, the
     Registry MUST reject with unknown_aid.

     The DPoP proof for key rotation MUST include htu, htm, iat, and jti.
     The Registry MUST reject a missing proof with dpop_proof_required and
     MUST reject an invalid, stale, or replayed proof with invalid_token.
     The Registry MUST store enough recent DPoP jti values for each AID to
     reject replay within the accepted DPoP clock-skew window.



  Singla                  Expires 15 November 2026              [Page 150]


  Internet-Draft                     AIP                          May 2026


     The Registry MUST reject the request with invalid_request unless all
     of the following conditions hold:

     1.  The percent-decoded path {aid} equals identity.aid.

     2.  The submitted identity.version equals the currently stored
         identity version plus exactly 1.

     3.  The submitted identity.public_key is an Ed25519 JWK conforming to
         the Agent Identity schema, and its kid equals identity.aid +
         "#key-" + identity.version.

     4.  The submitted object changes only version, public_key, and
         previous_key_signature; all other Agent Identity fields MUST be
         byte-for-byte identical to the currently stored Agent Identity
         Object.

     5.  previous_key_signature is present, is a non-empty base64url
         string, and verifies using the immediately previous stored public
         key over the complete submitted Agent Identity Object serialized
         per Section 2.1 with previous_key_signature temporarily set to
         "".

     The version check and the identity update MUST be performed in one
     atomic compare-and-commit operation against the currently stored
     identity version.  If another rotation commits first, or if the
     submitted identity.version is not exactly the currently stored
     version plus 1, the Registry MUST reject with
     identity_version_conflict (HTTP 409).  A Registry MUST NOT accept a
     rotation that skips a version number or overwrites a newer stored
     identity.

     Exact retries are idempotent.  If the submitted Agent Identity Object
     is byte-for-byte identical to the current stored Agent Identity
     Object, the Registry MUST return HTTP 200 with the current Agent
     Registration Metadata and MUST NOT update timestamps, key states, or
     historical-key records.  For this exact-retry case, the DPoP proof
     MAY verify against the current active key named by the submitted
     identity.  A different request body for the same version is not an
     idempotent retry and MUST be rejected with identity_version_conflict.











  Singla                  Expires 15 November 2026              [Page 151]


  Internet-Draft                     AIP                          May 2026


     On first successful commit, the Registry MUST atomically store the
     submitted Agent Identity Object as the current identity, mark the
     previous key as retired, retain the previous public verification key
     for historical validation according to Section 19.7, and update the
     registration metadata updated_at timestamp.  The successful response
     MUST be HTTP 200 with Content-Type: application/json and a body equal
     to the Agent Registration Metadata representation that a subsequent
     GET /v1/agents/{aid} would return.  The Registry MUST NOT process key
     rotation through POST /v1/agents.

  17.6.  Agent Public-Key Endpoints

     A conformant AIP Registry MUST implement GET /v1/agents/{aid}/public-
     key and GET /v1/agents/{aid}/public-key/{key-id}. These endpoints
     provide the key material and validity interval required by Section 9
     Step 3 and Section 9 Step 8d-2.

     A successful response MUST use HTTP 200 with Content-Type:
     application/json and a body conforming to public-key-
     response.schema.json.  The response MUST include aid, key_id, kid,
     jwk, valid_from, valid_until, and status.  The kid value MUST equal
     {aid} + "#" + key_id, and jwk.kid MUST equal kid.  The jwk member
     MUST contain Ed25519 public verification material.

     GET /v1/agents/{aid}/public-key returns the current active
     verification key for {aid}. For the active key, status MUST be
     "active".  The valid_until member MAY be null to indicate that the
     key has not yet been retired.

     GET /v1/agents/{aid}/public-key/{key-id} returns the retained key
     version identified by {key-id}, where {key-id} is the JOSE kid
     fragment without the leading #.  Historical responses MUST set status
     to "retired" when a later key version is active.  The Registry MUST
     retain historical keys according to Section 19.4.2.

     If {aid} is not registered, {key-id} is malformed, the requested key
     version is not found, or the requested key version is older than the
     Registry's conformant retention window, the Registry MUST reject with
     unknown_aid (HTTP 404).  Revocation, suspension, or deactivation of
     an AID MUST NOT suppress public-key lookup for retained keys; Relying
     Parties need those keys to verify signatures before applying
     revocation and lifecycle checks.









  Singla                  Expires 15 November 2026              [Page 152]


  Internet-Draft                     AIP                          May 2026


  17.7.  Agent Capability Manifest Endpoint

     A conformant AIP Registry MUST implement GET /v1/
     agents/{aid}/capabilities.  A successful response MUST use HTTP 200
     with Content-Type: application/json and a body conforming to
     capability-manifest.schema.json.  The returned manifest MUST be the
     current Registry-stored Capability Manifest for {aid}, and
     manifest.aid MUST equal the percent-decoded path {aid}.

     If {aid} is not registered, the Registry MUST reject with unknown_aid
     (HTTP 404).  If the Registry cannot return a stored manifest for a
     registered AID, or if the stored manifest is malformed, has an
     invalid signature, fails catalog constraint validation, or is not
     bound to {aid}, the Registry MUST reject with manifest_invalid.  The
     Registry MUST return the current manifest even if expires_at has
     passed; Relying Parties then reject with manifest_expired under
     Section 9 Step 9.

     A conformant AIP Registry MUST also implement PUT /v1/
     agents/{aid}/capabilities to replace the current Capability Manifest.
     The request body MUST conform to capability-manifest.schema.json,
     MUST have aid equal to the percent-decoded path {aid}, MUST use a
     version value exactly one greater than the Registry's current stored
     manifest version for that AID, and MUST have a valid signature from
     granted_by.  On success, the Registry MUST store the submitted
     manifest as the new current manifest and return HTTP 200 with the
     stored manifest body.  Unknown AIDs return unknown_aid; malformed
     manifests, invalid signatures, version conflicts, catalog constraint
     failures, and AID mismatches return manifest_invalid; submitted
     manifests whose expires_at has already passed return
     manifest_expired.

  17.8.  Agent Revocation Status Endpoint

     A conformant AIP Registry MUST implement GET /v1/
     agents/{aid}/revocation.  This endpoint returns the authoritative
     live revocation status used by Section 9 Step 7 for Tier 2
     validation.

     If the path {aid} does not identify a registered AID in the
     authoritative Registry, the Registry MUST reject with unknown_aid
     (HTTP 404).  If the AID is registered, the Registry MUST return HTTP
     200 with a JSON body conforming to revocation-status.schema.json,
     including when the AID has no active revocations.

     The response fields are:

     aid  The registered AID being checked.  This value MUST equal the



  Singla                  Expires 15 November 2026              [Page 153]


  Internet-Draft                     AIP                          May 2026


        percent-decoded path {aid}.

     checked_at  ISO 8601 UTC timestamp at which the authoritative
        Registry evaluated the revocation state.

     status  "active" when no active revocation applies, "restricted" when
        only scope_revoke or delegation_revoke applies, and "revoked" when
        full_revoke applies to the AID, when principal_revoke targets the
        AID, or when principal_revoke targets the root Principal DID
        associated with the AID's current registration authority.

     revoked  Boolean.  MUST be true when full_revoke or principal_revoke
        applies directly to the AID or through the AID's root Principal
        DID.  Relying Parties MUST reject Credential Tokens for the AID
        when this value is true.

     delegation_revoked  Boolean.  MUST be true when an active
        delegation_revoke applies.  Relying Parties MUST reject
        delegation-chain use rooted at this AID when this value is true.

     scopes_revoked  Array containing the union of active scope_revoke
        scopes for the AID.  The array is empty when no active scope
        revocation applies.

     active_revocations  Array of the signed Revocation Objects that
        currently affect this AID.  The array is empty when status is
        "active".  When a principal-wide principal_revoke affects the AID,
        this array MUST include the signed principal_revoke object whose
        target_id is the Principal DID.

     A registered, non-revoked AID therefore returns HTTP 200 with status:
     "active", revoked: false, delegation_revoked: false, an empty
     scopes_revoked array, and an empty active_revocations array.

  17.9.  Revocation Submission Endpoint

     A conformant AIP Registry MUST implement POST /v1/revocations.  The
     request body MUST be a Revocation Object conforming to revocation-
     object.schema.json.  Request validation, issuer authorization,
     idempotency, response behavior, CRL update effects, and child-
     propagation processing are defined by Section 11.2.










  Singla                  Expires 15 November 2026              [Page 154]


  Internet-Draft                     AIP                          May 2026


  17.10.  CRL Response

     A conformant AIP Registry MUST implement GET /v1/crl as the canonical
     origin endpoint for the AIP Certificate Revocation List.  The
     endpoint returns the signed CRL document defined in Section 11.3 and
     conforming to crl.schema.json.  Registries MAY publish an absolute
     CDN or distributed-object URI in the signed Registry Trust Record's
     signed.endpoints.crl; the origin endpoint and any published
     distribution URI MUST return the same current CRL payload or a byte-
     for-byte older payload that remains valid before its next_update.

     The CRL endpoint is not a generic paginated collection endpoint.
     Cursor pagination MUST NOT be applied to the revocations array of a
     signed CRL document because doing so would change the object covered
     by the CRL signature and could cause clients to validate against an
     incomplete revocation set.

     A Registry whose active CRL is too large to publish as a single
     efficient document MAY publish a segmented CRL.  In that mode, GET
     /v1/crl returns a signed CRL index document whose
     signed.publication_mode is "index", whose signed.revocations array is
     empty, and whose signed.segments array lists signed CRL segment
     documents.  Each segment URI, including /v1/crl/segments/{segment_id}
     when used by the origin Registry, MUST return Content-Type:
     application/aip-crl+json and a signed CRL document whose
     signed.publication_mode is "segment".

     The signed CRL index MUST identify the partitioning scheme with
     partition_key_alg: "sha-256-target-id-hex".  Segment ranges are
     inclusive ranges over the lowercase hexadecimal SHA-256 digest of the
     Revocation Object target_id string.  Segment ranges in one CRL index
     MUST be non-overlapping and together cover every active Revocation
     Object in the indexed CRL.  A Relying Party using a segmented CRL for
     bounded-staleness validation MUST retrieve and verify every segment
     whose range contains the partition key for any target identifier it
     must check, including the token's root Principal DID and every AID in
     the validated aip_chain.

     For each referenced segment, the Relying Party MUST verify the
     segment CRL signature against the Registry Trust Record identified by
     the segment's signed.trust_record_version, verify that the segment's
     registry_id, crl_id, sequence, issued_at, and next_update match the
     signed index, and verify that the JCS canonicalized segment document
     hashes to the segment reference's sha256 value.  If any required
     segment is unavailable or fails verification, bounded-staleness
     validation MUST fail with registry_unavailable.





  Singla                  Expires 15 November 2026              [Page 155]


  Internet-Draft                     AIP                          May 2026


  17.11.  Agent Heartbeat Endpoint

     A conformant AIP Registry MUST implement POST /v1/
     agents/{aid}/heartbeat.  This endpoint records liveness for the AID
     identified by the path parameter and is the submission mechanism used
     by the optional Dead Man's Switch in Section 21.8.

     The request MUST include Authorization: DPoP <token>, where <token>
     is a Credential Token issued by the same AID as the path parameter.
     The Registry MUST validate the Credential Token using the Section 9
     validation algorithm with the Registry as the Relying Party.  The
     token aud claim MUST identify either the Registry's registry_id or
     the heartbeat endpoint URI.  The token aip_scope MUST include
     registry.heartbeat.

     The request MUST include a DPoP proof bound to the HTTP method and
     heartbeat URI.  If the DPoP proof is absent, reject with
     dpop_proof_required.  If the proof is malformed or invalid, reject
     with invalid_token.

     After Credential Token validation, the Registry MUST verify that the
     path {aid} equals both the Credential Token issuer (iss) and the leaf
     Principal Token subject (aip_chain[n-1].sub).  If either value
     differs from the path AID, reject with invalid_token.  If the token
     does not contain registry.heartbeat, or if the current Capability
     Manifest does not grant registry.heartbeat, reject with
     insufficient_scope.

     On success, the Registry MUST record last_heartbeat_at using the
     Registry's receipt time.  Client-supplied body timestamps, if any,
     MUST NOT be used to advance liveness.  A successful heartbeat MAY
     also update the agent's last_active reputation metadata.

  17.12.  Approval Envelope Endpoints

     A conformant AIP Registry MUST implement the following additional
     endpoints for Approval Envelopes:

     +======+===================================+=======================+
     |Method| Path                              | Description           |
     +======+===================================+=======================+
     |POST  | /v1/approvals                     | Submit Approval       |
     |      |                                   | Envelope for approval |
     +------+-----------------------------------+-----------------------+
     |GET   | /v1/approvals/{id}                | Retrieve Approval     |
     |      |                                   | Envelope with step    |
     |      |                                   | statuses              |
     +------+-----------------------------------+-----------------------+



  Singla                  Expires 15 November 2026              [Page 156]


  Internet-Draft                     AIP                          May 2026


     |POST  | /v1/approvals/{id}/approve        | Principal approves    |
     |      |                                   | (Principal Wallet     |
     |      |                                   | call; sets            |
     |      |                                   | principal_signature)  |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/approvals/{id}/reject         | Principal rejects     |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/                              | Claim step for        |
     |      | approvals/{id}/steps/{n}/claim    | execution; returns    |
     |      |                                   | Step Execution Token  |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/                              | Mark step completed   |
     |      | approvals/{id}/steps/{n}/complete |                       |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/approvals/{id}/steps/{n}/fail | Mark step failed;     |
     |      |                                   | triggers compensation |
     +------+-----------------------------------+-----------------------+
     |GET   | /v1/approvals/{id}/steps/{n}      | Get step status (used |
     |      |                                   | by Relying Parties    |
     |      |                                   | for Step Execution    |
     |      |                                   | Token verification)   |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/approvals/{id}/compensation-  | Claim compensation    |
     |      | steps/{n}/claim                   | step                  |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/approvals/{id}/compensation-  | Mark compensation     |
     |      | steps/{n}/complete                | step completed        |
     +------+-----------------------------------+-----------------------+
     |POST  | /v1/approvals/{id}/compensation-  | Mark compensation     |
     |      | steps/{n}/fail                    | step failed           |
     +------+-----------------------------------+-----------------------+
     |GET   | /v1/approvals/{id}/compensation-  | Get compensation step |
     |      | steps/{n}                         | status (used by       |
     |      |                                   | Relying Parties for   |
     |      |                                   | Step Execution Token  |
     |      |                                   | verification)         |
     +------+-----------------------------------+-----------------------+

                                   Table 30

     *POST /v1/approvals validation:* The Registry MUST validate the
     request body as an ApprovalEnvelopeSubmission, reject any read-only
     stored-resource fields in that body, and perform all checks defined
     in Section 13.10 before accepting an Approval Envelope.  The Registry
     MUST return HTTP 201 with the StoredApprovalEnvelope, including the
     Registry-assigned status: "pending_approval" and initial step
     statuses, on success.




  Singla                  Expires 15 November 2026              [Page 157]


  Internet-Draft                     AIP                          May 2026


     *POST /v1/approvals/{id}/approve flow:* This endpoint is called by
     the Principal Wallet after the principal completes the signing
     ceremony.  The request body MUST contain the principal_signature
     field: a base64url EdDSA signature computed by the principal's
     Principal Wallet over the immutable approval signing input defined in
     Section 13.3.  That signing input is the accepted
     ApprovalEnvelopeSubmission content plus creator_signature and
     principal_signature: ""; it excludes Registry-managed status,
     approved_at, and step status/timestamp fields.  The signing key MUST
     be a verification method controlled by principal_id.  The Registry
     MUST verify this signature against the resolved principal_id DID
     Document before transitioning the envelope to approved.

     *Atomicity requirement for approval:* The Registry MUST implement
     POST /v1/approvals/{id}/approve and POST /v1/approvals/{id}/reject as
     atomic lifecycle transitions.  Approval MUST be a conditional update
     from pending_approval to approved and MUST succeed only when the
     request is committed before approval_window_expires_at.  Rejection
     MUST be a conditional update from pending_approval to rejected.  Only
     one concurrent approval or rejection request for the same Approval
     Envelope can succeed.  If another Principal Wallet, expiry job,
     cancellation cascade, approval, or rejection has already changed the
     envelope state, the Registry MUST reject the losing request with
     approval_state_conflict and MUST NOT overwrite the stored
     principal_signature, approved_at, or terminal state.  If the envelope
     is still in pending_approval and approval_window_expires_at has
     passed, the Registry MUST reject an approval request with
     approval_envelope_expired and transition or leave the envelope in
     expired.  A byte-for-byte retry of the winning approval request MAY
     return the stored approved envelope as an idempotent success.

     *Atomicity requirement for step claim:* The Registry MUST implement
     step-claim operations atomically, for example using optimistic
     locking or a distributed lock, to prevent two actors from claiming
     the same step simultaneously.  Only one claim MUST succeed; the other
     MUST receive approval_step_already_claimed.

     *Step endpoint request and response bodies:* Forward-step and
     compensation-step claim, complete, and fail request and response
     bodies MUST conform to the profiles in approval-step-
     endpoints.schema.json.  Complete and fail requests MUST present the
     compact Step Execution Token issued for the active claim.  The
     Registry MUST validate the SET, match it to the request path and
     stored claim jti, enforce the claim deadline, and process exact
     idempotent retries as defined in Section 13.8.






  Singla                  Expires 15 November 2026              [Page 158]


  Internet-Draft                     AIP                          May 2026


     *Step Execution Token format:* The Step Execution Token returned by
     POST /v1/approvals/{approval_id}/steps/{step_id}/claim or POST /v1/
     approvals/{approval_id}/compensation/{compensation_step_id}/claim is
     a Registry-issued JWT with JOSE typ: "AIP-SET+JWT", alg: "EdDSA", and
     a kid matching a JWK in active_verification_keys.step_execution of
     the Registry Trust Record version current at issuance time.  The
     protected JOSE header MUST also include aip_trv equal to that
     Registry Trust Record version.  Its payload claims are described in
     Section 13.8.  Its TTL MUST comply with the Step Execution Token TTL
     derivation rule in Section 5.4.1.

  17.13.  Resource Registration

     AIP Registries that support token exchange (Section 8.4) MUST
     maintain a resource registry mapping target resource URIs to their
     authorization configuration.  Each Registered Resource Record MUST
     conform to resource-record.schema.json and MUST include:

     resource_uri  string, REQUIRED.  The RFC 9728 resource identifier.

     authorization_server  string, REQUIRED.  The URI of the authorization
        server for this resource, either the AIP Registry itself or an
        external authorization server.

     enterprise_idp_required  boolean, OPTIONAL.  When true, token
        exchange requests targeting this resource MUST use the Enterprise
        IdP Federation Profile (Section 8.4.5).  Default: false.

     enterprise_idp_token_endpoint  string, CONDITIONAL.  REQUIRED when
        enterprise_idp_required is true.  The Enterprise IdP's token
        endpoint URI.

     enterprise_idp_client_id  string, CONDITIONAL.  REQUIRED when
        enterprise_idp_required is true.  The Registry's registered
        client_id with the Enterprise IdP.

     Resource records are addressed by resource_id, the lowercase
     hexadecimal SHA-256 digest of the UTF-8 resource_uri value.  The
     Registry MUST reject a create request whose path-derived or body-
     supplied resource_id does not equal that digest with
     registration_invalid.  The Registry MUST reject duplicate
     resource_uri create requests with HTTP 409 unless the submitted
     record is byte-for-byte identical to the stored record, in which case
     it MAY return the existing record.

     A Registry MUST NOT accept unauthenticated public writes to the
     resource registry.  The registering caller MUST be authenticated as a
     Registry operator, the resource owner, or another party authorized by



  Singla                  Expires 15 November 2026              [Page 159]


  Internet-Draft                     AIP                          May 2026


     local Registry policy.  The Registry MUST validate that resource_uri,
     authorization_server, and any enterprise_idp_token_endpoint are
     absolute HTTPS URIs unless a local non-production policy explicitly
     allows another URI scheme.

     When enterprise_idp_required is true, the Registry MUST reject the
     record unless enterprise_idp_federation_supported is true in Registry
     discovery metadata and both enterprise_idp_token_endpoint and
     enterprise_idp_client_id are present.  Token exchange requests whose
     resource parameter resolves to such a record MUST follow the
     Enterprise IdP Federation Profile in Section 8.4.5.  Token exchange
     requests for an unknown resource value MUST be rejected with
     invalid_target.

     The resource registration endpoints have the following semantics:
     POST /v1/resources creates a Registered Resource Record, GET /v1/
     resources/{resource_id} retrieves one record, PUT /v1/
     resources/{resource_id} replaces one record atomically, and DELETE
     /v1/resources/{resource_id} removes the record from future token-
     exchange matching.  Delete does not revoke already issued enterprise
     IdP access tokens; those tokens remain governed by the enterprise
     IdP's own lifetime and revocation mechanisms.

  17.14.  OAuth 2.1 Authorization Server

     A conformant AIP Registry supporting G3 grants MUST implement an
     OAuth 2.1 Authorization Server [I-D.ietf-oauth-v2-1] with the
     following requirements:

     1.  The authorization endpoint MUST be published in the Registry's
         well-known configuration at /.well-known/oauth-authorization-
         server per [RFC8414].

     2.  PKCE [RFC7636] with code_challenge_method: "S256" is REQUIRED for
         all authorization requests.

     3.  For G3 grant ceremonies, the authorization request MUST include
         aip_grant_request containing the compact-JWS-signed GrantRequest
         defined in Section 12.2, and the Authorization Server MUST
         enforce the G3 binding checks in Section 12.10 before issuing an
         authorization code.

     4.  The scope parameter MUST use AIP scope strings from the synced
         AIP Scope Catalog or accepted local extension policy.







  Singla                  Expires 15 November 2026              [Page 160]


  Internet-Draft                     AIP                          May 2026


     5.  The token endpoint MUST redeem an authorization code only against
         the immutable GrantRequest binding stored during authorization.
         It MUST reject unbound, expired, replayed, or binding-mismatched
         authorization codes with grant_request_invalid.

     6.  For G3 grant ceremonies, the token endpoint response MUST follow
         the G3 token endpoint response mapping in Section 12.10.  The
         access_token value is a transport alias for the compact Principal
         Token and MUST be byte-for-byte identical to
         grant_response.principal_token.

     7.  The Principal Token payload returned by the token endpoint MUST
         include acr and amr claims reflecting the authentication
         performed.

     8.  The authorization server MUST support the acr_values parameter to
         declare minimum identity-proofing requirements.

     9.  DPoP [RFC9449] MUST be supported on the token endpoint.

     If an authorization request is missing code_challenge, is missing
     code_challenge_method, or has a code_challenge_method value other
     than S256, the Authorization Server MUST reject the request with
     pkce_required.

     The token endpoint also serves RFC 8693 [RFC8693] token exchange.

  17.14.1.  Registry Metadata Additions

     The /v1/registry-metadata response MUST also include:

     registry_trust_uri (string)
        URI of the current Registry Trust Record.

     grant_tiers_supported (array)
        Supported grant tiers: ["G1", "G2", "G3"].

     acr_values_supported (array)
        Supported acr values.

     acr_equivalence_map (object)
        Optional JSON object whose keys are ACR value strings received in
        aip_chain[0] and whose values are arrays of ACR value strings that
        the key maps to.  A key ACR value satisfies a requirement for any
        ACR value in its array.  Registries MUST only declare downward
        equivalences, where received assurance is equal to or higher than
        required assurance under a documented ACR equivalence policy.  If
        absent, exact ACR matching is required with no exceptions.



  Singla                  Expires 15 November 2026              [Page 161]


  Internet-Draft                     AIP                          May 2026


     amr_values_supported (array)
        Supported amr values.

     oauth_authorization_server (string)
        URI of the OAuth AS metadata document; present only if G3 is
        supported.

     endpoints.resources (string)
        Resource registration collection endpoint.  REQUIRED when token
        exchange is supported.

     identity_proofing_required_for_tier2 (boolean)
        Whether this Registry requires G3 for Tier 2 operations.  When
        true, enforced during Registration Check 14c, Validation Step 8
        Post-Check C, and Validation Step 9d.

     mtls_client_certificate_profile (string)
        Client-certificate binding profile for Tier 3 operations.  When
        Tier 3 is accepted, this value MUST be "aip-san-uri-v1".

     mtls_trust_anchors_uri (string)
        HTTPS URI documenting the Tier 3 client-certificate trust anchor
        set and revocation-checking mechanism.  REQUIRED when Tier 3 is
        accepted.

     enterprise_idp_federation_supported (boolean)
        Whether the Registry supports the Enterprise IdP Federation
        Profile in Section 8.4.5.  SHOULD be present in all Registry
        Metadata documents.  Absence is treated as equivalent to false.
        Gateways that surface this capability through /.well-known/oauth-
        protected-resource SHOULD ensure the value is consistent with the
        Registry's declared support in this document.  A mismatch between
        the two documents MUST be treated as a Registry configuration
        error.

     enterprise_idp_token_exchange_grant_types_supported (array)
        Enterprise IdP grant types the Registry can use for secondary
        exchange.  Values SHOULD include RFC 7523 JWT bearer and/or RFC
        8693 token exchange when federation is supported.

     enterprise_idp_issuers_supported (array)
        OIDC issuer identifiers or issuer patterns accepted for enterprise
        principal assertions and secondary token exchange, subject to
        local trust policy.

     aip_catalog_uri (string)
        URI of the synced AIP Catalog bundle or mirror.




  Singla                  Expires 15 November 2026              [Page 162]


  Internet-Draft                     AIP                          May 2026


     aip_catalog_version (string)
        Draft-aligned catalog version, e.g. draft-02.

     aip_catalog_snapshot_id (string)
        Immutable Catalog Snapshot identifier.

     aip_catalog_sha256 (string)
        Lowercase SHA-256 digest of the exact catalog bundle bytes,
        formatted as sha256:<64hex>.

     step_claim_timeout_seconds (integer)
        Registry claim timeout for Approval Envelope steps.  MUST be 1-600
        seconds inclusive.

  17.15.  AIP Catalog Sync, Scope Map, and Namespace Map

     Concrete AIP scope, scope-family, and namespace registrations are
     defined by an immutable AIP Catalog Snapshot.  This specification
     defines the wire grammar, Registry sync requirements, integrity
     metadata, validation semantics, and minimum Draft-02 catalog content.
     The catalog defines the concrete entries and their metadata for each
     draft snapshot.

     The canonical list of built-in AIP scopes, scope families, and
     namespaces is the set of entries with class: "standard" in the
     applicable Catalog Snapshot.  Entries with class: "standard" in that
     snapshot are the only built-in AIP registrations for that draft line.
     A Registry, deployer, or Relying Party MUST NOT mint a new standard
     AIP scope, scope family, or namespace by local policy alone;
     interoperable standard entries MUST appear in an applicable AIP
     Catalog Snapshot.

     The Draft-02 Catalog Snapshot is identified by catalog_version:
     "draft-02" and catalog_snapshot_id: "https://provai.dev/aip/catalog/
     draft-02".  The authoritative Draft-02 Catalog Snapshot is the
     deterministic dist/catalog.json release artifact from the separate
     provai-dev/aip-catalog repository for the immutable Draft-02 release.
     A conformant Registry for this draft MUST publish, in /v1/registry-
     metadata, an HTTPS aip_catalog_uri from which the exact JSON Catalog
     Bundle can be retrieved and an aip_catalog_sha256 value containing
     the lowercase SHA-256 digest of the exact UTF-8 bytes retrieved from
     that URI.  A mirror is conformant only when it serves bytes whose
     SHA-256 digest equals the published aip_catalog_sha256 value and
     whose JSON content carries catalog_version: "draft-02", aip_draft:
     "draft-02", and catalog_source_uri: "https://github.com/provai-dev/
     aip-catalog".  The Registry metadata field aip_catalog_snapshot_id
     identifies the pinned snapshot; it is not required to be duplicated
     inside the catalog JSON bundle.



  Singla                  Expires 15 November 2026              [Page 163]


  Internet-Draft                     AIP                          May 2026


     Draft-02 conformance MUST be based on the pinned Catalog Snapshot
     identified above.  A Registry MUST NOT use a latest, latest-live,
     branch head, mutable tag, or other moving catalog input to determine
     standard Draft-02 scope, scope-family, namespace, or security
     metadata.  Changes to any standard entry, including changes to tier,
     destructive, requires_dpop, ttl_max_seconds, grant_tier_min,
     constraint_schema, status, or class, require a new
     catalog_snapshot_id, a new aip_catalog_sha256, and a corresponding
     AIP draft or protocol version update before they affect Draft-02
     conformance.

     The Draft-02 JSON Catalog Bundle MUST be generated by the validation
     and distribution tooling in the aip-catalog repository.  The bundle
     MUST contain top-level catalog_name, catalog_version, aip_draft,
     catalog_source_uri, scopes, scope_families, and namespaces members.
     The namespaces array MUST include standard entries for personal,
     enterprise, service, orchestrator, and ephemeral, and a reserved
     entry for registry.  The scope_families array MUST include standard
     entries for transactions.* and communicate.*. The scopes array MUST
     include standard entries for transactions, web.forms_submit,
     email.send, web.download, spawn_agents.create, spawn_agents.manage,
     and approvals.create.  A missing required standard entry, missing
     required security or provenance metadata field, stale generated
     bundle, or digest mismatch invalidates the Registry's Draft-02
     catalog conformance.

     For standard AIP scope entries in the Draft-02 catalog, every active
     or experimental scope with destructive: true MUST also have
     requires_dpop: true.  The Draft-02 catalog additionally marks non-
     destructive but high-risk external-effect scopes email.send,
     web.download, and web.forms_submit with requires_dpop: true.  A
     Registry mirror MUST NOT weaken these requires_dpop values for
     standard scopes.  The requires_dpop flag is additive: Tier 2 and Tier
     3 operations require DPoP under Section 9 Step 10 regardless of this
     flag, while Tier 1 scopes and endpoints can use the flag or endpoint
     policy to require DPoP.

     Deployers and Registry operators MAY expose non-standard scopes only
     as explicit extensions.  Extension entries intended for cross-
     Registry interoperability MUST be registered in the AIP Catalog.
     Until accepted in an applicable catalog snapshot, such entries are
     local extensions.  A deployer MUST NOT create a valid scope merely by
     including an unknown string in a Capability Manifest; the Registry
     MUST first accept and publish the extension entry in its Scope Map.
     Local or community extension scope identifiers MUST use the x. prefix
     followed by a namespace label controlled by the Registry or deployer,
     for example x.example.payments.release.  The namespace label MUST
     either be an active namespace entry in the Registry's Namespace Map



  Singla                  Expires 15 November 2026              [Page 164]


  Internet-Draft                     AIP                          May 2026


     or a local label documented by the Registry's extension policy, and
     that policy MUST state how control of the label is established.  The
     namespace label and all following segments MUST satisfy the scope
     string grammar below.  Local extensions MUST NOT shadow, override, or
     weaken any standard catalog scope, scope family, namespace, or
     reserved prefix.

     Extension scopes are not Tier 1 by default.  Every exposed scope
     entry, including local and community extensions, MUST carry explicit
     values for tier, destructive, requires_dpop, ttl_max_seconds,
     grant_tier_min, constraint_schema, status, class, owner, source, and
     change_type.  If a Registry cannot determine any required security or
     provenance metadata for an extension scope, it MUST NOT expose that
     scope as valid.  Registration, grant, or validation attempts that
     depend on such an incomplete scope MUST be rejected with
     registration_invalid at registration time, grant_request_invalid
     during grant consent, or invalid_scope at token validation time.

     The standard web.forms_submit scope is classified as Tier 2 in the
     Draft-02 catalog, with grant_tier_min: "G2" and ttl_max_seconds: 300.
     It does not inherit the generic web.* Tier 1 default because form
     submission can create external side effects including account
     changes, data submissions, and financial form submissions.

     AIP does not define a URN namespace for scope identifiers.  The
     canonical on-wire AIP scope value is the dot-notation scope string:

       scope_string = dot-separated-scope-name

     Scope strings in the Scope Map MUST match <dot-separated-scope-name>.
     This allows digits within each dot-separated segment after the first
     character.  The same short string form MUST be used in OAuth scope
     parameters and within AIP Credential Tokens (aip_scope array).
     Catalog entries also include a uri member for documentation and
     catalog linking.  Standard Draft-02 Catalog entries MUST use HTTPS
     URIs under https://provai.dev/aip/scopes/; these HTTPS URIs are not
     the on-wire OAuth scope values.

     A conformant AIP Registry MUST implement GET /v1/scopes returning a
     JSON object with catalog sync metadata and an array of scope entries.
     The response object MUST include aip_draft, catalog_version,
     catalog_snapshot_id, catalog_source_uri, catalog_sha256, synced_at,
     scopes, and pagination.  It MUST also include extension_policy_uri.
     The extension_policy_uri value MUST be non-null when the response
     includes any community scope entry or any locally documented
     extension scope and MAY be null otherwise.  Pagination MUST follow
     Section 17.20 and cursors MUST be bound to the advertised
     catalog_version.  Each scope entry MUST include id, uri, family,



  Singla                  Expires 15 November 2026              [Page 165]


  Internet-Draft                     AIP                          May 2026


     description, tier, destructive, requires_dpop, ttl_max_seconds,
     grant_tier_min, constraint_schema, status, class, owner,
     introduced_in, updated_in, change_type, and source.  The class value
     MUST be one of standard, community, or reserved.

     Principal Wallet consent UIs MUST use the standardized display titles
     in Section 12.3 for standard Draft-02 scopes.  For community or local
     extension scopes, the Registry's extension policy MUST provide a non-
     empty human-readable title and summary for each exposed extension
     scope before that scope can be used in a grant ceremony.  The display
     title or summary MUST NOT broaden the authorization represented by
     the scope metadata.

     When constraint_schema is non-null, it MUST be a JSON Schema Draft
     2020-12 fragment associated with the containing catalog_version.  Any
     change to a non-null constraint_schema MUST update the scope entry's
     updated_in value and MUST be reviewed as a catalog change.

     A conformant AIP Registry MUST implement GET /v1/namespaces returning
     a JSON object with catalog sync metadata and an array of namespace
     entries.  The response object MUST include aip_draft,
     catalog_version, catalog_snapshot_id, catalog_source_uri,
     catalog_sha256, synced_at, and namespaces.  It MUST also include
     pagination.  It MUST include extension_policy_uri when the response
     includes any community namespace entry or any locally documented
     extension namespace and MAY use null otherwise.  Pagination MUST
     follow Section 17.20 and cursors MUST be bound to the advertised
     catalog_version.  Each namespace entry MUST include id, description,
     reserved, spawnable, requires_task_id, lifecycle_rules, status,
     class, owner, introduced_in, updated_in, change_type, and source.
     The class value MUST be one of standard, community, or reserved.

     A Registry MUST expose only catalog entries that are present in its
     synced catalog snapshot or in an explicitly documented local or
     community extension policy.  A Relying Party MUST treat active
     entries as valid.  It MAY accept experimental entries only when local
     policy allows experimental behavior.  It MUST reject reserved,
     removed, unknown, or conflicting entries with invalid_scope for
     scopes or registration_invalid for registration-time namespace
     failures.











  Singla                  Expires 15 November 2026              [Page 166]


  Internet-Draft                     AIP                          May 2026


     Registries MUST validate submitted Capability Manifests and
     Capability Overlays against each applicable non-null
     constraint_schema from the synced Scope Catalog.  Registration
     submissions that fail this validation MUST be rejected with
     registration_invalid.  Capability Overlay submissions that fail this
     validation MUST be rejected with overlay_exceeds_manifest.  Relying
     Parties performing Step 9 or Step 9b validation MUST apply the same
     non-null constraint_schema fragments before treating manifest or
     overlay constraints as authoritative.

     Registries MUST expose the constraint_schema fragments that
     correspond to their advertised catalog_version.  A Registry MUST NOT
     silently substitute a schema fragment from a different catalog
     version for a standard scope.  Local or community extension schema
     changes MUST update the affected entry's updated_in value and MUST be
     documented by the Registry's extension policy before the changed
     schema is used for registration or token validation.

     Scope-family entries in the AIP Catalog define category notation such
     as transactions.* and communicate.*. Category notation is not a
     literal scope string and MUST NOT appear as a token aip_scope value
     unless it is separately registered as a concrete scope.

  17.16.  Capability Overlay Endpoints

     PUT /v1/agents/{aid}/overlays submits a Capability Overlay for the
     AID in the path.  The request body MUST conform to the Capability
     Overlay schema in Section 5.11, and the body aid value MUST equal the
     path {aid}.

     The Registry MUST reject overlays whose issued_by DID uses did:key
     with overlay_issuer_invalid.  The Registry MUST verify the overlay
     signature over the Section 2.1 signing input using the Ed25519
     verification method identified by signature_kid.  The DID portion of
     signature_kid MUST equal issued_by.  If the signature is absent,
     malformed, cannot be verified, or verifies under a key not controlled
     by issued_by, the Registry MUST reject with
     overlay_signature_invalid.

     For the tuple (aid, engagement_id, issued_by), a submitted overlay
     version MUST be strictly greater than the current active overlay
     version for that tuple.  If the submitted version is less than or
     equal to the current active version, the Registry MUST reject with
     overlay_version_conflict.  If the overlay expands the base Capability
     Manifest or fails catalog constraint validation, the Registry MUST
     reject with overlay_exceeds_manifest.





  Singla                  Expires 15 November 2026              [Page 167]


  Internet-Draft                     AIP                          May 2026


  17.17.  Engagement Endpoints

     A conformant AIP Registry supporting Engagement Objects MUST
     implement:

     +========+==============================+===========================+
     | Method | Path                         | Description               |
     +========+==============================+===========================+
     | POST   | /v1/engagements              | Create Engagement         |
     |        |                              | Object                    |
     +--------+------------------------------+---------------------------+
     | GET    | /v1/engagements/{id}         | Retrieve Engagement       |
     |        |                              | Object                    |
     +--------+------------------------------+---------------------------+
     | POST   | /v1/                         | Countersign proposed      |
     |        | engagements/{id}/countersign | Engagement Object         |
     +--------+------------------------------+---------------------------+
     | PUT    | /v1/engagements/{id}         | Update Engagement         |
     |        |                              | (append change log        |
     |        |                              | entry)                    |
     +--------+------------------------------+---------------------------+

                                    Table 31

     Create validation: The Registry MUST authenticate the submitter as
     the hiring_operator or as a caller authorized by Registry policy,
     verify hiring_operator_signature and the initial change-log entry
     signatures using the Engagement signature verification profile in
     Section 5.12, validate that all referenced participant AIDs exist and
     are not revoked, and assign status: "proposed" with a first change
     log entry whose seq is 1 and whose action is engagement_created.  The
     Registry MUST set version: 1 on the stored Engagement Object.  A
     create request that requests status: "active" without a valid
     deploying_principal_signature MUST be rejected with
     engagement_countersign_required.

     Countersign validation: POST /v1/engagements/{id}/countersign applies
     only to Engagement Objects in proposed status.  The request body MUST
     contain deploying_principal_signature and a new change log entry with
     action: "engagement_countersigned".  If deploying_principal_signature
     is absent, the Registry MUST reject the request with
     engagement_countersign_required.  The Registry MUST verify that the
     authenticated submitter is the deploying_principal, verify the
     countersignature and the change log entry signature using the
     Engagement signature verification profile in Section 5.12, and verify
     the entry seq is exactly current_max + 1.  If the entry seq is not
     exactly current_max + 1, the Registry MUST reject with
     change_log_sequence_invalid.  On success, the Registry MUST append



  Singla                  Expires 15 November 2026              [Page 168]


  Internet-Draft                     AIP                          May 2026


     the change log entry, store deploying_principal_signature, set
     status: "active", and set version to the appended entry's seq
     atomically.

     Update validation: The Registry MUST verify the submitter is an
     active participant, the change log entry's seq is exactly current_max
     + 1, and the entry signature is valid under the Engagement signature
     verification profile in Section 5.12.  If the seq value is missing,
     repeated, skipped, or otherwise not exactly current_max + 1, the
     Registry MUST reject with change_log_sequence_invalid.  The Registry
     MUST reject modifications to existing entries with
     change_log_immutable.  On success, the Registry MUST append the
     entry, apply the mutation represented by that entry, and set version
     to the appended entry's seq atomically.  The Registry MUST reject any
     PUT request that changes top-level engagement state without appending
     exactly one accepted change-log entry.

  17.18.  RPNP Subscription Endpoints

     A conformant AIP Registry supporting RPNP (Section 11.5) MUST
     implement:

      +========+========================+==============================+
      | Method | Path                   | Description                  |
      +========+========================+==============================+
      | POST   | /v1/subscriptions      | Create RPNP subscription     |
      +--------+------------------------+------------------------------+
      | GET    | /v1/subscriptions/{id} | Retrieve subscription status |
      +--------+------------------------+------------------------------+
      | DELETE | /v1/subscriptions/{id} | Cancel subscription          |
      +--------+------------------------+------------------------------+

                                   Table 32

     Subscription creation request bodies MUST conform to rpnp.schema.json
     subscription_request, and successful responses MUST conform to
     subscription_response.  Subscription creation MUST be authenticated
     using the subscriber_did-bound DPoP profiles defined in
     Section 11.5.2.  The webhook_uri MUST use HTTPS.  The Registry MUST
     reject non-HTTPS URIs with invalid_webhook_uri.  The Registry MUST
     apply the RPNP subscription authorization, scope-filter, and quota
     checks defined in Section 11.5.2 before creating the subscription.
     On success, the Registry MUST return HTTP 201 with the assigned
     subscription_id.

     GET /v1/subscriptions/{id} and DELETE /v1/subscriptions/{id} MUST use
     the same subscriber_did-bound authentication profile.  The
     authenticated subscriber_did MUST equal the subscription owner unless



  Singla                  Expires 15 November 2026              [Page 169]


  Internet-Draft                     AIP                          May 2026


     Registry administrator policy explicitly authorizes the caller to
     inspect or cancel subscriptions for other subscribers.  Otherwise,
     the Registry MUST reject with subscription_auth_required.  GET MUST
     return the current subscription_response.  DELETE MUST transition the
     subscription to cancelled and return the updated
     subscription_response.

  17.19.  Key Management and Rotation

     Registry trust evolution is defined in Section 7.4.7.  Planned
     rotation preserves the same registry_id and uses versioned Registry
     Trust Records with overlapping signatures, expiry, and rollback
     checks.  Emergency compromise recovery uses explicit re-bootstrap and
     MUST NOT be accepted automatically.

  17.20.  Pagination and Large Responses

     Registry endpoints that return collections and are not otherwise
     defined as signed snapshot artifacts MUST support cursor pagination.
     This requirement applies to collection-bearing endpoints such as GET
     /v1/scopes, GET /v1/namespaces, and collection members of GET /v1/
     agents/{aid}/reputation.  It does not apply to single-resource
     endpoints or to signed CRL documents, which use the CRL segmentation
     rules above.

     Paginated endpoints MUST accept limit and cursor query parameters.
     The limit value MUST be an integer from 1 to 1000 inclusive.  If
     limit is absent, the default is 100.  A Registry MAY apply a lower
     maximum for a specific endpoint, but the effective maximum MUST be at
     least 100.  The cursor value is opaque to clients and MUST be used
     only with the same endpoint and query filter set that produced it.
     Invalid limit or cursor values MUST be rejected with invalid_request.

     A paginated response MUST include the endpoint-specific collection
     member, such as scopes, namespaces, or revocation_history, containing
     no more than the effective limit.  It MUST also include a pagination
     object with limit, next_cursor, and has_more.  The next_cursor value
     MUST be null when has_more is false.  Servers MUST use a
     deterministic ordering for each collection and MUST bind cursors to a
     stable collection snapshot.  If a cursor refers to a snapshot that is
     no longer available, the Registry MUST reject the request with
     invalid_request.

  18.  Error Handling







  Singla                  Expires 15 November 2026              [Page 170]


  Internet-Draft                     AIP                          May 2026


  18.1.  Error Response Format

     Unless a referenced OAuth binding normatively requires OAuth-native
     error syntax, every AIP protocol error response MUST use HTTP status
     code 4xx or 5xx, MUST use Content-Type: application/json, and MUST
     carry a body conforming to error-response.schema.json in the JSON
     Schema Index.  Implementations MUST NOT return HTTP 200 for error
     conditions.

     The error response body MUST include error, error_description, and
     aip_version.  It MAY include error_uri, correlation_id, and details.
     The error value MUST be the exact registered error-code string.  The
     error_description value is human-readable diagnostics only; clients
     MUST NOT parse it for protocol decisions.  Machine-readable metadata
     MUST be carried in details using one of the detail object profiles
     defined below and in the schema.

     Every AIP-aware error response MUST include an X-AIP-Version response
     header as defined in Section 8.1.  The body aip_version value MUST
     equal the X-AIP-Version response header.  For unsupported_version,
     the responder MUST set X-AIP-Version to a protocol version it
     supports for that endpoint and SHOULD include X-AIP-Supported-
     Versions.  The details object for unsupported_version MUST include
     supported_versions and SHOULD include the rejected version values
     when they are available.

     For error responses conforming to this specification, X-AIP-Version
     and the body aip_version value MUST be "0.3", except that a responder
     rejecting an unsupported version uses the supported version it
     selected for the error response.

     EXAMPLE (informative):

     {
       "error": "unsupported_version",
       "error_description": "Unsupported AIP version.",
       "aip_version": "0.3",
       "error_uri": "https://provai.dev/errors/unsupported_version",
       "correlation_id": "err_01HZX7M7N2M6M2T8K8F5Z3Q9Y1",
       "details": {
         "type": "unsupported_version",
         "requested_version": "0.2",
         "header_aip_version": "0.2",
         "token_aip_version": null,
         "supported_versions": ["0.3"]
       }
     }




  Singla                  Expires 15 November 2026              [Page 171]


  Internet-Draft                     AIP                          May 2026


  18.2.  Standard Error Codes

     invalid_token  HTTP 401.  Token malformed, invalid signature, or
        invalid claims.

     token_expired  HTTP 401.  Token exp is in the past.

     token_replayed  HTTP 401.  Token jti seen before within validity
        window.

     invalid_request  HTTP 400.  Request syntax, query parameter,
        pagination cursor, or endpoint-specific request parameter is
        invalid.

     unsupported_version  HTTP 400.  X-AIP-Version or token aip_version is
        missing, unsupported, or mutually inconsistent.

     dpop_proof_required  HTTP 401.  DPoP proof is required for the
        request but the DPoP header is absent.  Malformed or invalid DPoP
        proofs return invalid_token.

     agent_revoked  HTTP 403.  The AID has been revoked.

     insufficient_scope  HTTP 403.  Operation not within granted scopes.

     invalid_delegation_depth  HTTP 403. delegation_depth mismatch or
        exceeds max_delegation_depth.

     chain_token_expired  HTTP 403.  Principal Token in aip_chain expired.

     delegation_chain_invalid  HTTP 403.  Structural error in delegation
        chain.

     manifest_invalid  HTTP 403.  Capability Manifest unavailable,
        signature failed, or AIP Scope Catalog constraint validation
        failed.

     manifest_expired  HTTP 403.  Capability Manifest expires_at passed.

     approval_envelope_invalid  HTTP 400.  Approval Envelope malformed,
        signature failed, dependency invalid, or value/hash mismatch.

     approval_envelope_expired  HTTP 403.  The Approval Envelope was not
        approved before approval_window_expires_at.

     approval_not_found  HTTP 404.  Approval Envelope ID not found.

     approval_state_conflict  HTTP 409.  Approval Envelope state changed



  Singla                  Expires 15 November 2026              [Page 172]


  Internet-Draft                     AIP                          May 2026


        before the requested approval or rejection transition could be
        committed.

     approval_step_prerequisites_unmet  HTTP 403. triggered_by step not
        yet completed.

     approval_step_already_claimed  HTTP 409.  Step already claimed by
        another actor.

     approval_step_not_claimed  HTTP 409.  Step Execution Token presented
        before the Registry has accepted a claim for that step.

     approval_step_action_mismatch  HTTP 403.  Presented action_parameters
        hash does not match stored action_hash.

     approval_step_invalid  HTTP 403.  Step Execution Token verification
        against Registry failed.

     compensation_failed  HTTP 409.  An Approval Envelope compensation
        step failed and the envelope is in terminal failed state requiring
        out-of-band remediation.

     engagement_cancelled  HTTP 409.  The referenced Approval Envelope or
        step was cancelled because its parent Engagement Object was
        terminated.  The operation cannot proceed.

     grant_request_expired  HTTP 400.  AIP-GRANT request_expires_at
        passed.

     grant_request_replayed  HTTP 400.  AIP-GRANT grant_request_id seen
        before.

     grant_request_invalid  HTTP 400.  GrantRequest malformed, expired,
        missing from a G3 authorization request, signature failed,
        inconsistent with OAuth request binding, or cannot be resolved to
        trusted catalog scope display metadata for consent.

     grant_rejected_by_principal  HTTP 403.  Principal declined the grant.

     grant_nonce_mismatch  HTTP 400.  GrantResponse nonce does not match.

     grant_tier_insufficient  HTTP 403.  Registered grant_tier is absent,
        unrecognised, or below the Grant Tier required for the operation's
        security Tier.

     registration_invalid  HTTP 400.  Registration Envelope malformed or
        failed validation, including missing or invalid grant_tier.




  Singla                  Expires 15 November 2026              [Page 173]


  Internet-Draft                     AIP                          May 2026


     aid_already_registered  HTTP 409.  The submitted AID or public key is
        already associated with a registered, non-revoked AID.

     unknown_aid  HTTP 404.  AID not registered in any accessible
        Registry.

     identity_version_conflict  HTTP 409.  Agent Identity key rotation
        version is stale, skips a version, or conflicts with a committed
        rotation.

     revocation_invalid  HTTP 400.  Revocation Object is malformed, uses a
        reserved externally submitted reason, has an invalid timestamp, or
        has an invalid or unverifiable signature.

     revocation_unauthorized  HTTP 403.  Revocation issuer is not
        authorized for the target or revocation type.

     revocation_conflict  HTTP 409.  Revocation identifier was previously
        accepted with different object content.

     registry_unavailable  HTTP 503.  Registry or a required DID resolver
        could not be reached or timed out.

     rate_limit_exceeded  HTTP 429.  Rate limit for this operation
        exceeded; see Section 19.

     mtls_required  HTTP 403.  Tier 3 operation without mTLS.

     invalid_scope  HTTP 400.  Requested scope is unknown, reserved,
        removed, retired (including bare spawn_agents), conflicting with
        the synced AIP Scope Catalog, or outside an explicitly documented
        local/private extension policy.

     principal_did_method_forbidden  HTTP 403.  Principal DID method is
        not permitted for the operation Tier; Tier 2 and Tier 3 require
        did:web.

     identity_proofing_insufficient  HTTP 403.  G3 identity proofing is
        absent or does not satisfy requested acr_values.

     enterprise_policy_denied  HTTP 403.  The enterprise IdP denied the
        token exchange request due to Conditional Access, ABAC, or
        equivalent enterprise policy.  The agent's principal lacks
        sufficient enterprise-level authorization for the requested
        resource.  Context: Section 8.4.5.2.

     idp_client_misconfigured  HTTP 500.  The AIP Registry's enterprise




  Singla                  Expires 15 November 2026              [Page 174]


  Internet-Draft                     AIP                          May 2026


        IdP client credentials are invalid or expired.  This is a Registry
        configuration error, not an agent error.  Context:
        Section 8.4.5.2.

     invalid_grant  HTTP 400.  The enterprise IdP rejected the secondary
        token exchange grant.  Context: Section 8.4.5.2.

     enterprise_assertion_missing  HTTP 403.  Tier 3 validation required
        an aip_principal_assertion claim, but the Credential Token did not
        contain one.

     enterprise_assertion_invalid  HTTP 403.  The aip_principal_assertion
        JWT was malformed, could not be verified against the enterprise
        IdP JWKS, or used an issuer that is not accepted for the
        deployment.

     enterprise_assertion_principal_mismatch  HTTP 403.  The verified
        aip_principal_assertion subject did not match the root Principal
        Token's principal.id.

     a2a_originator_invalid  HTTP 400.  The aip_originator_aid claim is
        absent in an A2A delegated context, does not conform to the
        did:aip ABNF, equals the acting agent's own AID, or cannot be
        traced to the validated delegation chain.  Context: Section 10.4.

     endorsement_invalid  HTTP 400.  Endorsement Object validation failed,
        including invalid signature or out-of-range score.  Context:
        Section 14.2.

     gateway_config_invalid  HTTP 400.  A gateway OAuth Protected Resource
        Metadata document is internally inconsistent or violates AIP
        gateway metadata constraints.  Context: Section 7.5.

     grant_not_found  HTTP 404.  G1 grant_id not found or expired.

     grant_deployer_mismatch  HTTP 403.  G1 grant_id does not match
        deployer.

     pkce_required  HTTP 400.  G3 authorization request missing PKCE or
        not using code_challenge_method S256.

     registry_untrusted  HTTP 403.  Registry does not match principal DID-
        Document-declared Registry.

     overlay_exceeds_manifest  HTTP 400.  Overlay violates CO-1
        attenuation rule or AIP Scope Catalog constraint validation.

     overlay_issuer_invalid  HTTP 400.  Overlay issuer uses did:key.



  Singla                  Expires 15 November 2026              [Page 175]


  Internet-Draft                     AIP                          May 2026


     overlay_version_conflict  HTTP 409.  Overlay version not strictly
        increasing.

     overlay_signature_invalid  HTTP 400.  Overlay signature verification
        failure.

     engagement_terminated  HTTP 403.  Engagement has been terminated or
        completed.

     engagement_suspended  HTTP 403.  Engagement is currently suspended.

     engagement_participant_removed  HTTP 403.  Agent removed from
        engagement.

     engagement_gate_pending  HTTP 403.  Required approval gate not yet
        approved.

     engagement_not_found  HTTP 404.  Engagement ID not found.

     engagement_countersign_required  HTTP 400.  Missing required
        Engagement Object countersignature.

     engagement_signature_invalid  HTTP 400.  Engagement Object top-level
        signature or change-log entry signature is missing, malformed,
        bound to the wrong DID, uses an unsupported key, or fails
        verification.

     change_log_immutable  HTTP 400.  Attempt to modify change log entry.

     change_log_sequence_invalid  HTTP 400.  Out-of-sequence change log
        append.

     subscription_auth_required  HTTP 401.  RPNP subscription request
        missing DPoP, using an invalid DPoP proof, or failing to bind
        subscriber_did to the DPoP key or Authorization credential.

     subscription_scope_forbidden  HTTP 403. scope_filter: "all" rejected
        by Registry policy.

     invalid_webhook_uri  HTTP 400.  Webhook URI not HTTPS.

     subscription_limit_exceeded  HTTP 429.  RPNP subscription limit
        reached.

     invalid_target  HTTP 400.  Token exchange resource not registered.






  Singla                  Expires 15 November 2026              [Page 176]


  Internet-Draft                     AIP                          May 2026


  18.3.  Error Detail Types

     The details member is optional unless this section states that it is
     REQUIRED for a specific error.  When present, it MUST conform to one
     of the detail object profiles in error-response.schema.json.  A
     detail object MUST NOT weaken, contradict, or replace the registered
     meaning of the top-level error value.

     unsupported_version  The response MUST include an unsupported_version
        detail object containing supported_versions.  It SHOULD include
        requested_version, header_aip_version, and token_aip_version when
        those values are available.

     rate_limit_exceeded  The response MUST include Retry-After per
        [RFC6585] Section 4, the rate limit headers defined in
        Section 19.1, and a rate_limit detail object containing operation,
        limit, and reset_at.

     registry_unavailable  The response SHOULD include Retry-After per
        [RFC9110] and SHOULD include a registry_dependency detail object
        identifying the unavailable dependency and whether the condition
        is retryable.

     chain_token_expired  The response SHOULD include a delegation_depth
        detail object identifying the expired chain element's
        delegation_depth, and MAY include chain_index,
        principal_token_jti, and expires_at.

     invalid_delegation_depth  The response SHOULD include a
        delegation_depth detail object containing the submitted
        delegation_depth and, when applicable, max_delegation_depth.

     invalid_scope and insufficient_scope  The response SHOULD include a
        scope detail object listing the scope or scopes that caused
        rejection and, when catalog metadata influenced the decision, the
        catalog_snapshot_id and catalog_sha256 used.

     manifest_invalid and overlay_exceeds_manifest  When rejection is
        caused by scope-catalog constraint validation, the response SHOULD
        include a scope detail object listing the failing scopes and
        catalog snapshot metadata.

     Conflict errors  For identity_version_conflict,
        approval_state_conflict, revocation_conflict,
        overlay_version_conflict, and change_log_sequence_invalid, the
        response SHOULD include a conflict detail object identifying the
        resource and the current, submitted, or expected version,
        sequence, or state when available.



  Singla                  Expires 15 November 2026              [Page 177]


  Internet-Draft                     AIP                          May 2026


     Approval step errors  For approval_step_prerequisites_unmet,
        approval_step_already_claimed, approval_step_not_claimed,
        approval_step_action_mismatch, and approval_step_invalid, the
        response SHOULD include an approval_step detail object containing
        approval_id and step_id.

     Grant request errors  For grant_request_expired,
        grant_request_replayed, grant_request_invalid, and
        grant_nonce_mismatch, the response SHOULD include a grant detail
        object containing grant_request_id when the request identifier is
        known.

     Field validation errors  For invalid_request, registration_invalid,
        revocation_invalid, approval_envelope_invalid,
        overlay_signature_invalid, engagement_countersign_required,
        engagement_signature_invalid, change_log_immutable, pkce_required,
        invalid_webhook_uri, and invalid_target, the response SHOULD
        include a field detail object identifying the rejected field or
        parameter when a single field caused the rejection.

     Subscription errors  For subscription_auth_required,
        subscription_scope_forbidden, and subscription_limit_exceeded, the
        response SHOULD include a subscription detail object when a
        subscription identifier, subscriber DID, or limit value is known.

  19.  Rate Limiting and Abuse Prevention

     Rate limiting protects the Registry from denial-of-service attacks,
     registration floods, and validation-driven key lookup storms.  A
     public Registry that permits unrestricted write operations or
     validation-driven lookups is exploitable in ways that undermine the
     security guarantees of the entire ecosystem.

  19.1.  Rate Limit Response Format

     When rate limiting is applied, the Registry MUST return HTTP 429 with
     the following headers:














  Singla                  Expires 15 November 2026              [Page 178]


  Internet-Draft                     AIP                          May 2026


        +=======================+==========+=========================+
        | Header                | Required | Description             |
        +=======================+==========+=========================+
        | Retry-After           | MUST     | Seconds until the       |
        |                       |          | client may retry, or a  |
        |                       |          | HTTP-date per [RFC9110] |
        +-----------------------+----------+-------------------------+
        | X-RateLimit-Limit     | SHOULD   | The request limit for   |
        |                       |          | this window             |
        +-----------------------+----------+-------------------------+
        | X-RateLimit-Remaining | SHOULD   | Remaining requests in   |
        |                       |          | this window             |
        +-----------------------+----------+-------------------------+
        | X-RateLimit-Reset     | SHOULD   | Unix timestamp when the |
        |                       |          | window resets           |
        +-----------------------+----------+-------------------------+
        | X-RateLimit-Policy    | MAY      | Human-readable          |
        |                       |          | description of the      |
        |                       |          | applicable policy       |
        +-----------------------+----------+-------------------------+

                                   Table 33

     The response body MUST conform to the error response format
     (Section 18.1) with error: "rate_limit_exceeded" and a human-readable
     error_description identifying the rate-limited operation and the
     applicable window.

  19.2.  Per-Endpoint Rate Limit Categories

     The Registry MUST implement separate rate limit buckets for each of
     the following operation categories.  The numeric limits below are
     RECOMMENDED default ceilings for unauthenticated or baseline clients.
     Registry operators MAY enforce lower ceilings when observed traffic
     patterns or threat models require stricter throttling, and MAY grant
     higher ceilings to authenticated or verified clients where this
     section allows higher limits.  Rate-limit conformance is based on
     implementing the separate buckets, enforcing a documented effective
     limit for each bucket, and returning the response format in
     Section 19.1.  The exact numeric thresholds are operational policy
     unless a requirement below uses MUST.

  19.2.1.  Category R1 - Registration writes

     (POST /v1/agents):






  Singla                  Expires 15 November 2026              [Page 179]


  Internet-Draft                     AIP                          May 2026


     *  Per-principal-DID: RECOMMENDED limit of 20 agent registrations per
        hour.  This prevents a single compromised principal key from
        flooding the Registry with rogue agent registrations.

     *  Per-source-IP: RECOMMENDED limit of 50 registrations per hour
        across all principals.  This prevents registration floods from a
        single network origin, regardless of the principal DID presented.

     *  Global: Registries SHOULD implement a global registration rate
        limit appropriate to their infrastructure capacity.

  19.2.2.  Category R2 - Key rotation writes

     (PUT /v1/agents/{aid}):

     *  Per-AID: RECOMMENDED limit of 10 key rotations per 24-hour window.
        Legitimate key rotation is infrequent; high frequency suggests
        automated abuse or a compromised orchestrator.

  19.2.3.  Category R3 - Revocation writes

     (POST /v1/revocations):

     *  Per-issuer-DID: RECOMMENDED limit of 100 revocations per hour.
        Higher limits are legitimate for enterprise orchestrators managing
        large ephemeral agent fleets.  Registries MAY issue higher limits
        to verified principals.

     *  Registries MUST apply special throttling to propagate_to_children:
        true revocations that would cascade to more than 100 descendants,
        as these trigger recursive Registry writes.  A revocation that
        would cascade to more than 100 descendants SHOULD be queued and
        processed asynchronously, with the Registry returning HTTP 202
        (Accepted) and a status URI rather than blocking on the full
        cascade.

  19.2.4.  Category R4 - Validation-driven key reads

     (GET /v1/agents/{aid}/public-key/{key-id}, GET /v1/
     agents/{aid}/revocation):

     *  Per-requesting-IP: RECOMMENDED limit of 1,000 requests per minute
        across all AIDs.  Validation-driven reads are triggered by token
        verification; legitimate Relying Parties have bounded lookup
        rates.






  Singla                  Expires 15 November 2026              [Page 180]


  Internet-Draft                     AIP                          May 2026


     *  Per-AID: RECOMMENDED limit of 200 reads per minute.  A single AID
        being looked up 200 times per minute from varied IPs is likely the
        subject of a coordinated replay attack; rate limiting per AID
        allows the Registry to throttle targeted abuse.

     *  Registries SHOULD offer API key authentication for Relying Parties
        whose legitimate validation rates exceed these limits (e.g., high-
        traffic APIs that verify thousands of agent tokens per minute).

  19.2.5.  Category R5 - CRL reads

     (GET /v1/crl direct-origin reads and the published endpoints.crl
     retrieval URI):

     *  The published CRL retrieval URI MUST be served from a CDN or
        distributed infrastructure (Section 11.3).  Direct-origin CRL
        reads to /v1/crl SHOULD be rate limited per IP to 100 requests per
        minute to protect against CDN bypass attacks.  CDN-served
        responses have no normative rate limit constraint.

  19.2.6.  Category R6 - Endorsement writes

     (POST /v1/endorsements):

     *  Per-from-AID: RECOMMENDED limit of 500 endorsements per hour.
        This prevents an AID from artificially inflating another AID's
        endorsement_count through automated submission.

     *  Self-endorsement (from_aid == to_aid) MUST be rejected at the
        application layer before rate limits are checked.

  19.2.7.  Category R7 - Approval Envelope writes and step claims

     (POST /v1/approvals, POST /v1/approvals/{id}/steps/{n}/claim):

     *  Per-principal-DID: RECOMMENDED limit of 100 Approval Envelopes per
        hour.  Approval Envelopes represent human-authorised workflows;
        high frequency is anomalous.

     *  Per-actor-AID per envelope: step claims are naturally rate-limited
        by the sequential structure of the workflow.  No additional rate
        limit is required for step claims within a single envelope.

  19.3.  Registration Abuse Prevention

     Beyond rate limiting, the Registry MUST implement the following
     structural checks to prevent registration abuse:




  Singla                  Expires 15 November 2026              [Page 181]


  Internet-Draft                     AIP                          May 2026


  19.3.1.  AID uniqueness enforcement

     The Registry MUST check AID uniqueness under a distributed lock or
     equivalent atomic mechanism.  Two simultaneous registration requests
     for the same AID MUST result in exactly one succeeding and one
     receiving an appropriate error (Section 6.2 Check 4).

  19.3.2.  Principal delegation chain verification at registration

     The Registry MUST verify that the principal_token in the Registration
     Envelope was issued by a DID that is resolvable and has not been
     subjected to a full_revoke or principal_revoke RevocationObject in
     the Registry.  A revoked principal MUST NOT be permitted to register
     new agents.

     For the purposes of this check, a *revoked principal* is defined as a
     principal DID (principal_token.principal.id) against which a
     principal_revoke Revocation Object has been submitted to this
     Registry.  The Registry MUST maintain an index of principal DIDs
     associated with principal_revoke revocations and MUST reject new
     Registration Envelopes where principal_token.principal.id matches a
     DID in this index.  A principal_revoke whose target_id is a Principal
     DID is principal-wide.  A principal_revoke whose target_id is a
     specific agent AID is scoped to that AID's authorisation and does not
     by itself block registration of unrelated AIDs for the same
     principal.

  19.3.3.  Registration flood from shared principals

     Operational guidance (non-normative): a high number of registrations
     under a single principal DID can be an abuse signal.  A Registry can
     apply local policy, such as deployer review or out-of-band business
     verification, when registrations from one principal exceed an
     implementation-defined threshold.  A value such as 1,000 agents can
     be used as an example review trigger, but this specification does not
     define a protocol-visible proof of legitimate use, an interoperable
     review mechanism, or a conformance threshold for shared-principal
     registration volume.

  19.3.4.  Public Registry challenge for unauthenticated deployers

     Registries that permit registration without deployer authentication
     (open Registries) SHOULD implement a lightweight proof-of-work or
     CAPTCHA mechanism for registrations where the deployer DID is self-
     asserted, unauthenticated to the Registry, or otherwise not trusted
     by local Registry policy.





  Singla                  Expires 15 November 2026              [Page 182]


  Internet-Draft                     AIP                          May 2026


  19.4.  Validation-Driven Lookup Limits

     Key lookup amplification occurs when an adversary presents many
     tokens with distinct kid values, forcing the Registry to perform a
     lookup for each.  Mitigations:

  19.4.1.  Key version caching

     Relying Parties MUST cache resolved public keys for a given kid for
     up to 300 seconds.  Repeated validation of tokens with the same kid
     SHOULD NOT trigger repeated Registry lookups within the cache window.

  19.4.2.  Historical key depth limit

     Registries MAY reject requests for key versions older than the
     historical key retention window defined in Section 19.7.  This
     prevents adversaries from constructing tokens with ancient, never-
     rotated keys to force deep history lookups without invalidating any
     conforming unexpired token.

     Relying Parties perform the Step 2a expiration preflight before
     historical key lookup.  Therefore an expired token MUST be rejected
     with token_expired before a missing historical key can produce
     unknown_aid.

  19.4.3.  kid validation at the Relying Party

     Relying Parties MUST validate that the kid in the token header
     matches the pattern: did:aip:<lowercase-namespace>:<32-lowercase-
     hex>#key-<positive-integer> before performing any Registry lookup
     (Validation Step 3).  Malformed kid values MUST be rejected with
     invalid_token without making a Registry call.

  19.5.  Approval Envelope Rate Limits

     Approval Envelope operations require specific abuse prevention
     because they involve asynchronous principal interactions and
     potential cascade effects.

  19.5.1.  Envelope submission rate

     Per Section 19.2, Category R7.

  19.5.2.  Pending envelope limit

     A Registry SHOULD enforce a maximum of 1,000 pending_approval
     envelopes per principal DID at any time.  Envelopes that expire
     transition to expired and free this quota.



  Singla                  Expires 15 November 2026              [Page 183]


  Internet-Draft                     AIP                          May 2026


  19.5.3.  Step claim timeout

     Step claims that are not completed or failed within the Registry's
     published step_claim_timeout_seconds value MUST be automatically
     failed by the Registry.  The timeout interval starts at the step's
     claimed_at timestamp.  The step_claim_timeout_seconds value MUST be
     an integer from 1 to 600 seconds inclusive and MUST be published in
     /v1/registry-metadata.

     This prevents a claimed step from blocking the workflow indefinitely
     due to a crashed or unresponsive agent.  Timeout-induced failure MUST
     trigger the same envelope failure and compensation evaluation as an
     explicit step failure reported by the actor.

  19.5.4.  Compensation cascade depth

     Compensation step execution is not rate-limited separately - it is a
     recovery mechanism whose scope is bounded by the number of forward
     steps (maximum 20).  No additional rate limit is required for
     compensation.

  19.6.  Graduated Backoff Requirements

     Clients that receive HTTP 429 responses MUST implement exponential
     backoff with jitter.  The minimum retry interval is the value in the
     Retry-After header.  Clients MUST NOT retry before Retry-After
     expires.

     Implementations SHOULD use the following backoff formula:

     BACKOFF_BASE = 1         ; fixed exponential base, in seconds
     MAX_DELAY    = 3600      ; hard ceiling, in seconds

     computed_delay = min(BACKOFF_BASE * 2^attempt, MAX_DELAY)
     jitter         = random(0, BACKOFF_BASE)
     retry_delay    = max(computed_delay + jitter, Retry-After)

     The Retry-After value from the 429 response acts as a mandatory
     minimum: clients MUST NOT retry before Retry-After seconds have
     elapsed, even if computed_delay + jitter is smaller.  When no Retry-
     After header is present, clients MUST treat it as 0 and rely solely
     on the exponential formula.

     Clients that continue to receive HTTP 429 after 5 exponential backoff
     attempts MUST cease retrying for a minimum of 1 hour and SHOULD alert
     an operator.  Persistent rate limiting at this scale indicates either
     a misconfigured client or a sustained attack pattern.




  Singla                  Expires 15 November 2026              [Page 184]


  Internet-Draft                     AIP                          May 2026


     Registries MUST track clients that consistently exceed rate limits
     and MAY temporarily block their source IPs or API keys after
     sustained abuse.  Blocking decisions are implementation-specific and
     are not normatively constrained by this specification.

  19.7.  Historical Key Retention Requirements

     A Registry that accepts key rotation for an AID MUST retain each
     retired public verification key for historical validation until at
     least:

     retention_not_before =
       retired_key.valid_until
       + max_credential_token_ttl_for_registry
       + accepted_clock_skew

     max_credential_token_ttl_for_registry is the largest effective
     Credential Token TTL that the Registry could have accepted for any
     active scope at the time the key was retired, after applying the Tier
     ceilings in Section 8.2 and the synced AIP Scope Catalog.  The
     accepted_clock_skew value MUST be at least 30 seconds.  Registries
     MAY retain retired keys longer than this minimum.  The RECOMMENDED
     operational retention window is 90 days after valid_until, but that
     window MUST be extended when the formula above yields a later time.

     Historical key retention is a validation-availability rule, not an
     authority extension.  Agents MUST stop issuing Credential Tokens with
     a retired private key immediately after a successful rotation, and
     Relying Parties MUST still reject tokens whose exp, delegation chain,
     or revocation state fails validation.

  20.  Versioning and Compatibility

     AIP uses separate identifiers for Internet-Draft document revisions
     and wire protocol compatibility.  The suffix in an Internet-Draft
     name, such as -00, -01, or -02, is a document revision identifier
     only.  It is not an AIP protocol version and MUST NOT appear in
     aip_version, X-AIP-Version, Credential Tokens, GrantRequests,
     Registry metadata, or other protocol messages.

     The aip_version claim and the X-AIP-Version HTTP header carry the AIP
     protocol compatibility version.  This Internet-Draft revision defines
     AIP protocol version 0.3.  Multiple Internet-Draft revisions MAY
     define the same protocol version when they contain editorial changes,
     clarifications, examples, schema corrections, or other changes that
     do not intentionally create a new wire compatibility class.





  Singla                  Expires 15 November 2026              [Page 185]


  Internet-Draft                     AIP                          May 2026


     AIP protocol versions follow Semantic Versioning compatibility
     intent, represented on the wire as MAJOR.MINOR.  Before v1.0, MINOR
     versions MAY include breaking changes.  A future Internet-Draft
     revision that intentionally introduces breaking wire behavior,
     incompatible validation semantics, or incompatible message schemas
     MUST allocate a new protocol version before publication, for example
     by moving from 0.3 to 0.4.  Backward-compatible clarifications and
     non-breaking errata MAY retain the existing aip_version.

     AIP Catalog snapshot identifiers, such as draft-02, are also separate
     from aip_version.  A Registry MAY report both its AIP protocol
     version and its synced Catalog snapshot, but verifiers MUST NOT treat
     a Catalog snapshot identifier or Internet-Draft revision as a
     substitute for protocol version negotiation.

     +=========================================+==============+==========+
     | Internet-Draft revision                 | AIP          | Catalog  |
     |                                         | protocol     | snapshot |
     |                                         | version      |          |
     +=========================================+==============+==========+
     | draft-singla-agent-identity-protocol-00 | 0.1          | draft-00 |
     +-----------------------------------------+--------------+----------+
     | draft-singla-agent-identity-protocol-01 | 0.2          | draft-01 |
     +-----------------------------------------+--------------+----------+
     | draft-singla-agent-identity-protocol-02 | 0.3          | draft-02 |
     +-----------------------------------------+--------------+----------+

              Table 34: Draft Revision to Protocol Version Mapping

     Catalog snapshots are immutable for conformance purposes.  A Registry
     claiming Draft-02 conformance MUST advertise aip_catalog_version:
     "draft-02", aip_catalog_snapshot_id: "https://provai.dev/aip/catalog/
     draft-02", and a pinned aip_catalog_sha256 digest as defined in
     Section 17.15.  A change to any standard Catalog entry or standard
     Catalog security metadata requires a new Catalog Snapshot identifier
     and MUST NOT be silently introduced under the existing Draft-02
     snapshot.

     Breaking changes from v0.2:

     *  aip_version is now "0.3" for conforming implementations.

     *  X-AIP-Version: 0.3 replaces X-AIP-Version: 0.2.

     *  The bare spawn_agents scope is retired; use spawn_agents.create
        and spawn_agents.manage (Section 17.15).

     *  Registration Envelopes MUST include grant_tier.



  Singla                  Expires 15 November 2026              [Page 186]


  Internet-Draft                     AIP                          May 2026


     *  Principal DID Documents for Tier 2 agents MUST include an
        AIPRegistry service entry.

     *  The /v1/registry-metadata response MUST include registry_id,
        registry_trust_uri, registry_name, and endpoints.  Registry Trust
        Records are versioned separately and MUST support sequential
        updates.

     *  Section 19.6 (Graduated Backoff Requirements): the backoff formula
        has been corrected to use exponential backoff with a base interval
        of 1 second, a multiplier of 2, and a maximum interval of 3600
        seconds, replacing the previous linear backoff formula.  This
        change ensures that Registry lookup storms are dampened under
        sustained failure conditions.

     Implementations MUST NOT silently accept tokens from unsupported
     versions without logging a version warning.

     A Relying Party or Registry conforming only to protocol version 0.3
     MUST reject any request, Credential Token, Step Execution Token,
     GrantRequest, or other AIP protocol message whose aip_version or X-
     AIP-Version value is absent, not "0.3", or mutually inconsistent,
     unless the implementation has explicitly implemented that other
     protocol version.  The error response MUST be unsupported_version and
     SHOULD include X-AIP-Supported-Versions and the unsupported value in
     the details object.  Implementations MUST NOT treat an unknown future
     version, including a numerically greater value such as 0.4, as
     forward-compatible by default.

  20.1.  Tier Conformance

      +====+============+========+========+==============+==============+
      |Tier| Revocation |DPoP    |mTLS    | grant_tier   | Principal    |
      |    |            |        |        |              | DID Method   |
      +====+============+========+========+==============+==============+
      |1   | CRL (15    |NOT     |NOT     | G1, G2, or   | Any non-     |
      |    | min)       |REQUIRED|REQUIRED| G3           | did:aip W3C  |
      |    |            |        |        |              | DID method;  |
      |    |            |        |        |              | see          |
      |    |            |        |        |              | requirements |
      |    |            |        |        |              | below        |
      +----+------------+--------+--------+--------------+--------------+
      |2   | Real-time  |REQUIRED|NOT     | G2 or G3;    | did:web; see |
      |    |            |        |REQUIRED| see          | requirements |
      |    |            |        |        | requirements | below        |
      |    |            |        |        | below        |              |
      +----+------------+--------+--------+--------------+--------------+
      |3   | Real-time  |REQUIRED|REQUIRED| G3           | did:web; see |



  Singla                  Expires 15 November 2026              [Page 187]


  Internet-Draft                     AIP                          May 2026


      |    | + OCSP     |        |        |              | requirements |
      |    |            |        |        |              | below        |
      +----+------------+--------+--------+--------------+--------------+

                                    Table 35

     Tier 1 Principal DID method  For Tier 1, the principal MAY use any
        W3C DID method except did:aip.  Principals using did:key are
        permitted for Tier 1 only.

     Principal DID method restrictions  did:aip is NEVER a valid Principal
        DID method for any Tier.  The principal.id field MUST NOT use the
        did:aip method.  Principals using any DID method other than
        did:web for Tier 2 or Tier 3 agents MUST be rejected with
        principal_did_method_forbidden.  For Tier 2 and Tier 3, the
        did:web DID Document MUST contain the AIPRegistry service entry
        required by Section 7.3.

     Tier 2 Registry identity-proofing policy  If
        identity_proofing_required_for_tier2 is true in Registry metadata,
        Tier 2 permits only G3 for that Registry.

     The table defines minimum Grant Tier conformance.  A higher-assurance
     Grant Tier MAY satisfy a lower security Tier, but a lower-assurance
     Grant Tier MUST NOT satisfy a higher security Tier.  Relying Parties
     enforce this relationship for each participating aip_chain AID at
     runtime in Section 9, Step 9d.

  21.  Security Considerations

     This section describes the security considerations for AIP
     implementations, including the threat model, cryptographic
     requirements, and recommended mitigations.

  21.1.  Threat Model

     AIP identifies the following threat categories:

     TS-1: Token Replay
        An adversary reuses a captured Credential Token.  Mitigation: JTI
        replay cache.

     TS-2: Key Compromise
        An adversary steals an agent's private key.  Mitigation: Key
        rotation, HSM storage.






  Singla                  Expires 15 November 2026              [Page 188]


  Internet-Draft                     AIP                          May 2026


     TS-3: Delegation Escalation
        A child agent exceeds granted scope.  Mitigation: Rule D-1 (Scope
        Inheritance), Step 9c validation.

     TS-4: Registry Impersonation
        A malicious Registry serves fake revocation status.  Mitigation:
        Well-known configuration, key pinning.

     TS-5: Principal Impersonation
        An adversary forges a Principal Token.  Mitigation: DID resolution
        verification.

     TS-6: Revocation Delay
        The gap between revocation issue and propagation.  Mitigation:
        Real-time RPNP for Tier 2.

     TS-7: Token Theft
        An adversary intercepts a token in transit.  Mitigation: TLS 1.2+,
        DPoP.

     TS-8: Child Agent Self-Replication
        An agent with spawn_agents.create creates children during TTL
        window.  Mitigation: Tier 2 with propagate_to_children.

     TS-9: Action Hash Manipulation
        An agent executes different action than approved.  Mitigation:
        Action hash verification at claim time.

     TS-10: Step Execution Token Misuse
        An adversary forges, replays, or re-targets a Step Execution Token
        to execute an Approval Envelope step outside the authorized actor,
        audience, or step context.  Mitigation: SET validation profile,
        Registry Trust Record step-execution keys, Step 10a verification,
        DPoP binding, and per-step status checks.

     TS-11: Approval Lifecycle Race
        Concurrent approval, rejection, expiry, cancellation, or claim
        operations produce inconsistent Approval Envelope state.
        Mitigation: atomic lifecycle transitions, compare-and-set or
        equivalent locking, terminal-state rules, and
        approval_state_conflict.










  Singla                  Expires 15 November 2026              [Page 189]


  Internet-Draft                     AIP                          May 2026


     TS-12: Orchestrator Cascade
        A compromised or over-privileged orchestrator uses one approval or
        delegation to trigger a larger cascade of dependent actions than
        the principal intended.  Mitigation: pre-declared Approval
        Envelope steps, per-step actor and action-hash verification, step
        count limits, dedicated destructive-scope approval, and SAGA
        compensation rules.

     TS-13: Overlay Injection
        An adversary injects or replays a Capability Overlay to expand or
        mis-scope an agent's effective capabilities.  Mitigation: Overlay
        signatures, issuer validation, monotonic overlay versions, CO-1
        attenuation-only validation, engagement scoping, and catalog
        constraint validation.

     TS-14: Engagement Tampering
        An adversary modifies Engagement Object participants, lifecycle
        state, approval gates, or change-log entries to alter
        authorization context.  Mitigation: required countersignatures,
        append-only signed change logs, strict sequence validation,
        participant authorization checks, and termination cascade rules.

     TS-15: Model Substitution
        An agent deployer registers with a trusted model identifier but
        executes a different model binary or version manifest.
        Mitigation: model.attestation_hash SHOULD be present for Tier 2
        deployments and MUST be present for Tier 3 deployments.  The
        Registry SHOULD accept a Tier 2 registration without
        model.attestation_hash only when it persists and returns the
        structured model_attestation_missing_tier2 registration warning
        defined in Section 6.2.  The Registry MUST reject a Tier 3
        registration when model.attestation_hash is absent.

  21.2.  Cryptographic Requirements

     +========================+=================+===============+========+
     | Operation              | Algorithm       | Specification | Status |
     +========================+=================+===============+========+
     | Signing / Verification | Ed25519         | [RFC8037]     | MUST   |
     |                        | (EdDSA)         |               |        |
     +------------------------+-----------------+---------------+--------+
     | Hashing                | SHA-256         | [FIPS-180-4]  | MUST   |
     +------------------------+-----------------+---------------+--------+
     | Key representation     | JWK             | [RFC7517]     | MUST   |
     +------------------------+-----------------+---------------+--------+

                 Table 36: Mandatory-to-Implement Cryptography




  Singla                  Expires 15 November 2026              [Page 190]


  Internet-Draft                     AIP                          May 2026


     This specification does not define an AIP key-exchange or encryption
     handshake.  X25519 and other key-agreement mechanisms are reserved
     for a future extension and are not mandatory-to-implement in Draft-
     02.  Implementations MUST NOT treat support for any key-agreement
     algorithm as a condition for conformance to this specification.

     This specification reserves ES256 (ECDSA P-256) and RS256 (RSA-
     PKCS1), as defined by [RFC7518], for possible future extensions but
     does not define registration, resolution, rotation, AID derivation,
     or DPoP binding rules for those suites in protocol version 0.3.
     Credential Tokens, Principal Tokens, Step Execution Tokens, DPoP
     proofs, Agent Identity keys, and Registry public-key responses
     conforming to this specification MUST use EdDSA over Ed25519.
     Implementations MUST reject ES256, RS256, and other algorithm values
     for those artifacts.

     Prohibited: none, HS256/384/512, RS512, MD5, SHA-1.  The alg header
     MUST be explicitly specified.  A DID verification method used to sign
     or verify a Credential Token, Principal Token, Step Execution Token,
     or DPoP proof MUST be an Ed25519 signing verification method.  X25519
     keys are key-agreement keys and MUST NOT be used for signing.

  21.3.  Proof-of-Possession (DPoP)

     DPoP is REQUIRED for every Tier 2 or Tier 3 operation.  It is also
     REQUIRED when any requested Tier 1 scope has requires_dpop: true in
     the synced AIP Scope Catalog, or when the target endpoint requires
     DPoP independently of scope metadata.  DPoP proofs MUST use EdDSA.























  Singla                  Expires 15 November 2026              [Page 191]


  Internet-Draft                     AIP                          May 2026


     +==================================================+================+
     | Operation or request class                       | DPoP           |
     |                                                  | requirement    |
     +==================================================+================+
     | Tier 1 operation with no DPoP-required           | Not required   |
     | scope and no endpoint policy                     | by AIP.        |
     +--------------------------------------------------+----------------+
     | Tier 1 operation containing any scope            | Required.      |
     | whose synced Catalog entry has                   |                |
     | requires_dpop: true                              |                |
     +--------------------------------------------------+----------------+
     | Tier 1 Registry endpoint that                    | Required.      |
     | independently requires DPoP, including           |                |
     | key rotation, heartbeat submission,              |                |
     | and RPNP subscription authentication             |                |
     +--------------------------------------------------+----------------+
     | Tier 2 operation                                 | Required for   |
     |                                                  | every request. |
     +--------------------------------------------------+----------------+
     | Tier 3 operation                                 | Required for   |
     |                                                  | every request, |
     |                                                  | in addition to |
     |                                                  | mTLS.          |
     +--------------------------------------------------+----------------+

                          Table 37: DPoP Applicability

     Endpoint-level DPoP requirements are independent of the operation's
     security Tier.  For example, PUT /v1/agents/{aid} key rotation and
     POST /v1/agents/{aid}/heartbeat require DPoP even when the affected
     agent was originally registered only for Tier 1 scopes.

     For standard AIP scopes, the Draft-02 catalog marks all destructive
     scopes and selected high-risk external-effect scopes as DPoP-
     required.  This includes deletion scopes, filesystem mutation and
     execution scopes, transactions, communication scopes, spawn-agent
     scopes, and the non-destructive but high-risk email.send,
     web.download, and web.forms_submit scopes.  The web.forms_submit
     scope is Tier 2 in the Draft-02 catalog because form submissions can
     create external account, data, or financial effects.

     *DPoP Proof Header:*









  Singla                  Expires 15 November 2026              [Page 192]


  Internet-Draft                     AIP                          May 2026


     {
       "typ": "dpop+jwt",
       "alg": "EdDSA",
       "jwk": {
         "kty": "OKP",
         "crv": "Ed25519",
         "x": "<base64url public key>",
         "kid": "<DID URL>"
       }
     }

     *DPoP Proof Payload:*

     {
       "jti": "<UUID v4>",
       "htm": "<HTTP method, uppercase>",
       "htu": "<scheme + host + path, no query or fragment>",
       "iat": "<Unix timestamp>",
       "ath": "<BASE64URL(SHA-256(token))>"
     }

     Relying Party validation: Verify alg is EdDSA, verify htm/htu/iat,
     check jti replay, verify ath, verify signature, and verify the DPoP
     public key binding for the presented token type.  For an agent-issued
     Credential Token, jwk.kid MUST match the Credential Token protected
     header kid.  For a Step Execution Token, jwk.kid MUST identify
     Ed25519 public key material controlled by the SET sub actor AID; it
     MUST NOT be the Registry step-execution key that signed the SET.

     The htu claim is the DPoP target URI binding.  It MUST match the
     absolute target URI of the current request, excluding query and
     fragment components and using the normalization rules in [RFC9449].
     A proof captured for one Relying Party, Registry, host, path, or
     method is not transferable to another target: validation MUST fail on
     htu or htm before replay-cache state is considered.

     The ath claim binds the proof to the presented token.  Its value MUST
     be the unpadded base64url encoding of the SHA-256 hash of the exact
     compact Credential Token or Step Execution Token value from the
     Authorization header, excluding the authorization scheme, surrounding
     whitespace, and DPoP proof.  When DPoP is required, the authorization
     scheme is DPoP.

     DPoP proof jti replay state is verifier-local.  A verifier MUST
     maintain a DPoP replay cache separate from the Credential Token
     replay cache and keyed by (kid, jti).  The cache window MUST be at
     least the accepted DPoP proof age window: 300 seconds before receipt
     plus 30 seconds of future clock skew, unless a server-provided DPoP



  Singla                  Expires 15 November 2026              [Page 193]


  Internet-Draft                     AIP                          May 2026


     nonce is required under [RFC9449].  When nonce validation is used,
     the replay cache MUST retain entries for at least the nonce lifetime.
     AIP does not require a global or cross-Registry DPoP replay cache
     because cross-target replay is rejected by htu, htm, and ath
     validation.

  21.4.  Key Management

     Private keys MUST NOT be stored in plaintext at rest, transmitted in
     protocol messages, or included in logs.  Private keys SHOULD be
     stored in an HSM, secure enclave, OS-level keychain, or an equivalent
     protected key store where available.

     A private key satisfies the at-rest protection requirement when at
     least one of the following conditions is met:

     1.  The key is generated and used inside an HSM, secure enclave,
         operating-system keychain, cloud KMS, or comparable protected key
         store that prevents ordinary application processes from reading
         the raw private key material.

     2.  The key is stored only as ciphertext produced by envelope
         encryption using AES-256-GCM, or an equivalent authenticated-
         encryption scheme with at least 128-bit security strength, unique
         nonce or IV use per encryption key, integrity authentication of
         the ciphertext, and associated data that binds the ciphertext to
         the AID, key identifier, key version, and intended key purpose.

     A protected key store or encryption design is equivalent for this
     specification only if it enforces access control for key use and key
     administration, separates key-encryption keys from encrypted private-
     key blobs, supports key-encryption-key rotation without exposing
     plaintext private keys, records administrative key export or deletion
     events, and does not depend on hard-coded wrapping keys or wrapping
     keys stored in the same plaintext database row, file, or object as
     the encrypted private key.  Backup copies of private keys MUST
     satisfy the same controls as primary copies.

     The protected-key-store recommendation is a local implementation
     conformance requirement, not a wire-verifiable protocol condition.
     Registries and Relying Parties cannot determine from Credential
     Tokens or Registry API requests whether an implementation uses an
     HSM, secure enclave, keychain, or equivalent mechanism.  They MUST
     NOT treat protected-key-store use as a Registry acceptance check or
     Credential Token validation precondition.  Deployment profiles MAY
     require external audit, attestation, or certification of key-storage
     controls using the audit evidence profile below.




  Singla                  Expires 15 November 2026              [Page 194]


  Internet-Draft                     AIP                          May 2026


     *Deployment key-management audit evidence:* A deployment profile that
     requires audit evidence for local key-management controls MUST define
     an audit interval and MUST collect, at minimum, the following
     evidence without recording private key material, seed material, or
     plaintext recovery secrets:

     1.  Key inventory records identifying each AID, key identifier,
         identity.version, key creation time, key activation time, key
         retirement time when applicable, and the protected storage
         boundary used for the key.

     2.  Control evidence that private keys are not stored in plaintext at
         rest, transmitted in protocol messages, or included in logs.
         Acceptable evidence includes configuration attestations, HSM or
         secure-enclave policy exports, operating-system keychain policy
         exports, or signed operator attestations bound to a deployment
         profile.

     3.  Rotation records for every key rotation, including the old key
         identifier, new key identifier, submitted Agent Identity version,
         previous_key_signature verification result, Registry acceptance
         time, and the time at which issuance with the retiring private
         key stopped.

     4.  Compromise-response records for every key_compromised event,
         including the Revocation Object identifier, affected AID, time of
         revocation submission, and delegation re-establishment records if
         a replacement AID is registered.

     5.  For sub-agent delegation where the parent generates the child
         key, provisioning and deletion records containing the parent AID,
         child AID, provisioning time, secure channel or key-wrapping
         mechanism identifier, deletion time for any parent-held child
         private-key copy, and the local process or operator identity that
         performed the deletion.

     Audit records for key_compromised events MUST NOT include verbatim
     Credential Token or Step Execution Token payloads.  Token metadata
     (AID, jti, scope list, iat, exp) is sufficient for key-compromise
     timeline reconstruction and is the maximum permissible audit record
     content for token-related events.










  Singla                  Expires 15 November 2026              [Page 195]


  Internet-Draft                     AIP                          May 2026


     Audit evidence MAY be reviewed by deployment operators, external
     auditors, or certification programs, but it is not exchanged as part
     of Credential Token validation.  A Registry or Relying Party MUST NOT
     reject an otherwise valid protocol message solely because this audit
     evidence is absent from the wire message.  Unless a deployment claims
     the Deployment Key-Management Audit Profile in Section 23.3,
     compliance with these local key-management controls is self-attested
     by the implementation's conformance claim.

     *Key rotation:* Generate a new keypair, increment version, include
     previous_key_signature signed by the retiring key, and submit the new
     public key to the Registry.  The Registry MUST retain the retiring
     public verification key according to the historical key retention
     rule in Section 19.7.  The agent MUST stop issuing new tokens with
     the retiring private key after rotation succeeds.

     *Key compromise response:* Immediately revoke with reason:
     key_compromised, register new AID with new keypair, re-establish
     delegations.

  21.5.  Token Security

     All tokens MUST be transmitted over TLS 1.2 or higher (TLS 1.3
     RECOMMENDED).  MUST NOT transmit over unencrypted HTTP.

     *JTI replay cache:* Keyed by (iss, jti); window at least max TTL for
     served scopes; shared cache for distributed deployments.  The issuer
     AID is the replay domain: an agent MUST NOT reuse a jti across
     different delegation chains, principals, grants, scopes, or
     audiences.

     *Audience validation:* MUST validate aud claim.  Mismatch returns
     invalid_token.

  21.6.  Tier 3 mTLS Certificate Profile

     Tier 3 operations require mutual TLS with an X.509 client certificate
     that binds the TLS client to the effective actor AID.  The binding
     MUST use the certificate subjectAltName extension, not the subject DN
     or common name.

     1.  The Relying Party MUST validate the client certificate path per
         [RFC5280] to a trust anchor explicitly configured for the target
         Registry, resource server, or deployment profile.  The public Web
         PKI MUST NOT be treated as sufficient for AIP actor binding
         unless that CA set is explicitly configured as the deployment's
         Tier 3 client-certificate trust anchor set.




  Singla                  Expires 15 November 2026              [Page 196]


  Internet-Draft                     AIP                          May 2026


     2.  The certificate MUST be within its validity interval, MUST permit
         digital signatures in keyUsage when keyUsage is present, and MUST
         contain the id-kp-clientAuth extended key usage when
         extendedKeyUsage is present.

     3.  The certificate MUST contain exactly one URI subjectAltName value
         that matches the did:aip AID syntax.  That URI SAN value is the
         certificate actor AID.  The Relying Party MUST compare it byte-
         for-byte to the effective actor AID after ordinary URI SAN string
         extraction; it MUST NOT use subject DN, common name, email SAN,
         DNS SAN, or organization fields for actor binding.

     4.  If the client certificate is absent, the Relying Party MUST
         reject with mtls_required.  If path validation fails, required
         key-usage or EKU checks fail, the AIP URI SAN is absent, more
         than one AIP URI SAN is present, or the AIP URI SAN does not
         equal the effective actor AID, the Relying Party MUST reject with
         invalid_token.

     5.  The Relying Party MUST perform certificate revocation checking
         using OCSP per [RFC6960] or a deployment-profile mechanism that
         provides at least equivalent freshness and issuer authorization.
         An equivalent deployment-profile mechanism MUST, at minimum, bind
         status to the certificate issuer or delegated status authority,
         provide signed or otherwise authenticated certificate status,
         define a maximum status freshness interval no weaker than the
         OCSP policy it replaces, fail closed on unavailable or
         indeterminate status, and be documented in the deployment's
         mtls_trust_anchors_uri material.  A revoked client certificate
         MUST be rejected with agent_revoked.  An unavailable, stale, or
         indeterminate certificate revocation status MUST be rejected with
         invalid_token.

     A Registry or deployment that accepts Tier 3 registrations or
     advertises Tier 3 operation support MUST document the client-
     certificate trust anchor set and revocation-checking mechanism.  If
     this information is published through Registry Metadata, the fields
     are mtls_client_certificate_profile and mtls_trust_anchors_uri.

  21.7.  Delegation Chain Security

     Default max_delegation_depth MUST NOT exceed 3.  Hard cap is 10.
     Circular delegation MUST be detected and rejected.








  Singla                  Expires 15 November 2026              [Page 197]


  Internet-Draft                     AIP                          May 2026


     Ephemeral agents MUST have non-null task_id.  The Registry MUST auto-
     revoke ephemeral agents when their lifecycle_expires_at deadline
     passes, as defined in Section 15.  A Registry that leaves an
     ephemeral AID active after that deadline is non-conformant, even if
     Relying Parties would separately reject expired Principal Tokens or
     Capability Manifests during validation.

     Parent agents that generate child-agent private keys during sub-agent
     delegation MUST delete any retained copy after successful
     provisioning.  This requirement is not wire-verifiable by Registries
     or Relying Parties; it is an implementation conformance requirement
     for the parent agent's key-management boundary.  Deployment profiles
     that audit this requirement MUST use the sub-agent provisioning and
     deletion evidence defined in Section 21.4.

  21.8.  Registry Security

     All write operations MUST be authenticated.  Revocation issued_by,
     kid, issuer authorization, and signature verification MUST follow the
     ordered Revocation Submission Validation algorithm in Section 11.2.

     Registry read endpoint availability is an operational service-level
     objective, not a wire-protocol conformance condition.  Deployment
     profiles MAY define measurable availability targets, measurement
     intervals, exclusions, evidence, and remedies.  This specification
     does not define conformance failure solely by an uptime percentage.
     CRL MUST be served from CDN.

     Relying Parties MUST NOT trust the aip_registry claim in a Credential
     Token as sole indicator.  For Tier 2, the authoritative Registry MUST
     be verified via the root principal's DID Document.

  21.9.  Revocation Security

     Every Revocation Object MUST be signed.  Unsigned or invalidly signed
     objects MUST be rejected.

     *Dead Man's Switch (Optional):* Registry MAY issue full_revoke for
     agents that fail to submit an authenticated heartbeat to POST /v1/
     agents/{aid}/heartbeat within a configured window (RECOMMENDED: 24
     hours).  The heartbeat authentication and liveness timestamp rules
     are defined in Section 17.11.

     Registries that enable the Dead Man's Switch for an AID MUST measure
     the timeout from the Registry-recorded last_heartbeat_at value or, if
     no heartbeat has been accepted, from the AID registration time.  When
     issuing an automatic revocation for heartbeat timeout, the Registry
     SHOULD use revocation reason heartbeat_timeout.



  Singla                  Expires 15 November 2026              [Page 198]


  Internet-Draft                     AIP                          May 2026


     *Timing attack mitigation:* Short ttl_max_seconds values for
     sensitive scopes in the synced AIP Scope Catalog limit exploitation
     windows.

  21.10.  Approval Envelope Security

     *Action hash integrity:* The action_hash binds principal approval to
     specific action parameters.  Registry MUST reject any claim where
     recomputed hash does not match stored action_hash.

     *Double-spend prevention:* Atomic step-claim ensures each step
     claimed by exactly one actor.

     *Envelope replay prevention:* approval_id is UUID v4 unique per
     envelope.  Registries MUST reject duplicate approval_id values.

  21.11.  Privacy Considerations

     AIP is designed for zero-trust environments.  No personally
     identifiable information (PII) is transmitted in Credential Tokens
     beyond the AID and delegation chain.

     Registries MUST NOT log or retain Credential Token or Step Execution
     Token payloads beyond validation.  Relying Parties MUST NOT store
     tokens after validation.

     The principal_id in Principal Tokens enables attribution for
     compliance but does not inherently reveal principal identity to
     Relying Parties.

  22.  JSON Schema and Catalog Artifact Index

     The following JSON Schema definitions are normatively referenced
     throughout this specification.  They are part of the archived
     publication package for this draft in JSON Schema Draft 2020-12
     format under schemas/. The Draft-02 AIP Catalog Bundle is maintained
     as the deterministic dist/catalog.json release artifact in the
     separate aip-catalog (https://github.com/provai-dev/aip-catalog)
     repository.  The working repository at aip-rfc (https://github.com/
     provai-dev/aip-rfc) is a convenience mirror; a branch head, mutable
     tag, or /latest schema URI is not a normative artifact.

     For this draft, the immutable schema identifier for each listed
     schema is the $id value ending in /draft-02.  Implementa


