Cross-Domain AuthZ Information sharing for Agents
draft-diaconu-agents-authz-info-sharing-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jean Diaconu , Marcelo Yannuzzi , Hervé Muyal , Frank Brockners , Nik Kale , Ankit Agarwal , Jeffrey Hickman , Amritha Lal | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-diaconu-agents-authz-info-sharing-01
Internet Engineering Task Force J. Diaconu
Internet-Draft M. Yannuzzi
Intended status: Standards Track H. Muyal
Expires: 5 February 2027 F. Brockners
N. Kale
Cisco
A. Agarwal
Skyfire
J. Hickman
Ory Corp
A. Lal
AWS
4 August 2026
Cross-Domain AuthZ Information sharing for Agents
draft-diaconu-agents-authz-info-sharing-01
Abstract
Distributed Multi-Agent Systems consist of Agents and MCP Servers
operating across multiple administrative domains, each with its own
Identity Providers (IdPs) and Authorization Servers (AS).
This document discusses the challenges and solution approaches for
sharing authorization information securely and flexibly across
domains, including the use of dynamic identity, interoperable claims,
and verifiable credentials.
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 5 February 2027.
Diaconu, et al. Expires 5 February 2027 [Page 1]
Internet-Draft AuthZ Sharing for Agents August 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Abbreviations / Definitions . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Cross-Domain Tool Invocation . . . . . . . . . . . . . . 5
4.2. Enterprise Partnership Integration . . . . . . . . . . . 6
4.3. Multi-Vendor Workflow Orchestration . . . . . . . . . . . 6
4.4. Supply Chain Data Exchange . . . . . . . . . . . . . . . 7
4.5. Regulatory Compliance Across Jurisdictions . . . . . . . 7
5. Requirements Summary . . . . . . . . . . . . . . . . . . . . 7
6. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 8
6.1. Solution Approach 1: Dynamic Client Registration (RFC
7591) . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Solution Approach 2: SCIM extensions . . . . . . . . . . 9
6.3. Solution Approach 3: Client-ID Metadata . . . . . . . . . 10
6.4. Solution Approach 4: Client-ID Metadata + W3C Verifiable
Credentials Extension . . . . . . . . . . . . . . . . . . 12
6.4.1. Delegation Semantics for Cross-Domain Multi-Agent
Workflows . . . . . . . . . . . . . . . . . . . . . . 14
6.4.2. Agent Authorization Verifiable Credential Profile . . 19
6.5. Relationship to JWT Profile Approaches . . . . . . . . . 22
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Client-ID Metadata Example . . . . . . . . . . . . . . . 22
7.2. Verifiable Credential Example . . . . . . . . . . . . . . 23
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Security Considerations . . . . . . . . . . . . . . . . . 25
9.1.1. Threat Model for Cross-Domain Authorization
Sharing . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Informative References . . . . . . . . . . . . . . . . . 33
Diaconu, et al. Expires 5 February 2027 [Page 2]
Internet-Draft AuthZ Sharing for Agents August 2026
Appendix A. Mapping Mechanisms to Deployment Contexts . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
Distributed Multi-Agent Systems, consisting of Agents and Model
Context Protocol (MCP) Servers, are increasingly deployed across
multiple administrative domains. Each domain typically operates its
own Identity Providers (IdPs) and Authorization Servers (AS),
creating a fundamental challenge: how can an agent from Organization
A securely prove its identity and authorization to resources in
Organization B?
While OAuth 2.0 and related specifications provide authorization
frameworks for human users and pre-registered clients, the emergence
of autonomous agent systems operating across organizational
boundaries presents new challenges that existing mechanisms do not
fully address.
This challenge is distinct from traditional cross-domain identity
federation for human users. Humans rarely delegate authority through
multiple organizational boundaries. Agents routinely do so--an
orchestrator agent in Domain X may invoke a tool agent in Domain Y,
which accesses an MCP server in Domain Z. Existing authorization
mechanisms such as OAuth 2.0 Dynamic Client Registration [RFC7591]
and Token Exchange [RFC8693] assume single-domain operation or pre-
established relationships, and do not address the dynamic, multi-hop
delegation patterns that characterize modern agentic systems.
This document analyzes the cross-domain agent authorization problem
and evaluates solution approaches. The proposed solution extends
OAuth 2.0 Client-ID Metadata
[I-D.ietf-oauth-client-id-metadata-document] with W3C Verifiable
Credentials [W3C.VCDM2.0] to enable dynamic identity establishment
without pre-registration across domains, cryptographically verifiable
authorization claims that travel with the agent, multi-hop delegation
with monotonic scope narrowing and accountability chains, and
selective disclosure of sensitive authorization attributes.
The document is structured as follows: Section 3 defines key
terminology. Section 4 presents use cases demonstrating cross-domain
scenarios. Section 9.1.1 identifies threats specific to cross-domain
authorization sharing. Section 5 establishes requirements and
evaluates solution approaches. Section 9.1 covers security
considerations.
Diaconu, et al. Expires 5 February 2027 [Page 3]
Internet-Draft AuthZ Sharing for Agents August 2026
Enterprise deployment of AI agents is moving faster than the identity
and authorization practices that govern them. Recent industry
reporting, protocol roadmap work, and public vulnerability
disclosures point to the same gap: agents are connected to production
tools, data, and workflows without consistent per-agent identity,
scoped delegation, cross-domain authorization, or revocation
semantics. A February 2026 concept paper from the US National
Cybersecurity Center of Excellence proposes a demonstration project
applying existing identity and authorization standards, including
OAuth and the Model Context Protocol, to AI agents, which indicates
that this gap is now a recognized standards problem
[NIST.NCCoE.AgentIdentity].
The scale of unauthenticated deployment is measurable. A 2026
measurement study of remote MCP servers found that a large fraction
expose tools without any authentication, and that the OAuth
deployments which do exist commonly carry authentication flaws
[MCP.AuthMeasurement]. This is the condition this document
addresses: when an agent in one domain presents itself to an
Authorization Server in another, identity and authorization
information has to be verifiable, not assumed.
Between February and April 2026, several public incidents exercised
the threat categories described in this document. Autonomous agents
obtained remote code execution against production infrastructure,
reached an internal AI platform's database in under two hours, and
exploited missing authentication in MCP server implementations.
These incidents are mapped to the threat model in Section 9.1.1.4.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Abbreviations / Definitions
Agent An autonomous entity that performs tasks on behalf of a user
or another program within a multi-agent system.
MCP Server A program that exposes specific capabilities, like data
access or tools, to AI models through the Model Context Protocol
(MCP).
AS (Authorization Server) A server that issues authorization tokens
to clients after successfully authenticating them.
Diaconu, et al. Expires 5 February 2027 [Page 4]
Internet-Draft AuthZ Sharing for Agents August 2026
IdP (Identity Provider) A service that creates, manages, and
verifies digital identities for users and service users, often for
accessing multiple applications and services.
Subject The principal (user or service).
Claim Essentially a piece of information asserted about a subject.
Domain Scope over which a specific, uniform set of security policies
and user management rules are enforced.
VCDM 2.0 Verifiable Credentials Data Model 2.0, a W3C standard for
expressing verifiable credentials on the web.
VC Verifiable Credential, a digital credential that is
cryptographically secure and can be verified independently.
SD-JWT Selective Disclosure JSON Web Token, a JWT that allows the
holder to disclose only specific parts of the token.
DID Decentralized Identifier, a new type of identifier that enables
verifiable, self-sovereign digital identities.
4. Use Cases
The following use cases demonstrate scenarios where cross-domain
agent authorization presents challenges not addressed by existing
single-domain mechanisms.
4.1. Cross-Domain Tool Invocation
A coding assistant agent operated by Developer Tools Inc. needs to
invoke a code review tool provided by Code Analysis Corp. The tool
is exposed as an MCP Server protected by Code Analysis Corp's
Authorization Server.
Cross-Domain Challenge Developer Tools Inc.'s agent must present
credentials that Code Analysis Corp's AS can verify, despite
having no pre-existing trust relationship. The AS must determine
what operations the agent may perform based on claims issued by a
foreign domain.
Requirements Verifiable agent and MCP server identity across domain
boundaries, authorization claims that are interpretable by the
receiving domain.
Diaconu, et al. Expires 5 February 2027 [Page 5]
Internet-Draft AuthZ Sharing for Agents August 2026
4.2. Enterprise Partnership Integration
Company A partners with Company B to provide integrated customer
support services. Company A deploys a support agent that needs to
access Company B's customer ticketing system and knowledge base to
resolve customer issues.
Cross-Domain Challenge Company A's agent authenticates using Company
A's IdP and holds a Verifiable Credential issued by Company A.
Company B's Authorization Server has no trust relationship with
Company A's IdP--it cannot verify Company A's tokens. Company B
needs a mechanism to verify the agent's identity and authorization
claims without requiring bilateral federation setup for every
partner.
Requirements Dynamic identity verification across domains,
verifiable compliance attestations, and scope restrictions that
Company B's AS can enforce based on Company A's authorization
grants.
4.3. Multi-Vendor Workflow Orchestration
A security operations workflow involves agents from multiple vendors:
an orchestrator agent from Security Vendor X coordinates a threat
intelligence agent from Vendor Y and a remediation agent from Vendor
Z. The orchestrator must delegate appropriate permissions to each
specialized agent.
Cross-Domain Challenge The orchestrator in Domain X must delegate
authority to agents in Domains Y and Z. Each receiving domain
must verify the delegation chain, ensure the delegated scope does
not exceed what the originating principal authorized, and maintain
an auditable record of the delegation chain. Receiving domains
must ensure that the authorization decisions do not rely on
revoked, suspended, or superseded delegations by performing
runtime delegation chain verification according to the local
policy.
Requirements Multi-hop delegation with scope narrowing, cross-domain
accountability chains, privacy-preserving identity claims, and
domain-specific policy enforcement at each trust boundary
crossing.
Diaconu, et al. Expires 5 February 2027 [Page 6]
Internet-Draft AuthZ Sharing for Agents August 2026
4.4. Supply Chain Data Exchange
A manufacturer's inventory management agent needs to query suppliers'
availability systems. Multiple suppliers operate their own
authorization infrastructure. The agent must access each supplier's
MCP servers with appropriate credentials.
Cross-Domain Challenge Each supplier's AS must verify the
manufacturer's agent without requiring manual pre-registration.
Dynamic Client Registration [RFC7591] would require the agent to
register separately with each supplier's AS, creating operational
overhead and not providing cryptographic verification of the
agent's authorization claims from its home domain. The agent may
need different permission levels at different suppliers based on
partnership agreements. Suppliers must be able to audit which
manufacturer agents accessed their data.
Requirements Dynamic agent provisioning across multiple foreign
domains, verifiable identity without pre-registration, and domain-
specific scope mappings.
4.5. Regulatory Compliance Across Jurisdictions
A financial services agent operating in the EU needs to access data
from a partner institution in the US. Both jurisdictions have
different regulatory requirements.
Cross-Domain Challenge The receiving domain's AS must verify that
the requesting agent's compliance attestations meet local policy
requirements. The VC issued by the originating domain asserts
compliance with GDPR; the receiving domain must determine whether
this satisfies its own data handling requirements without assuming
equivalence of compliance frameworks.
Requirements Verifiable compliance attestations that receiving
domains can evaluate against local policies, and data sensitivity
clearance, verification across regulatory boundaries.
5. Requirements Summary
A system for cross-domain sharing of authorization information of
agents needs to meet the following set of requirements:
* *Dynamic Identity for Agents and MCP Servers:* The Agents and MCP
Servers can onboard dynamically and get an assigned identity in
the IdP.
Diaconu, et al. Expires 5 February 2027 [Page 7]
Internet-Draft AuthZ Sharing for Agents August 2026
* *Interoperability Across Domains:* The system must enable
interaction between Agents across different domains.
* *Flexible Definition of Claims:* Claims should be adaptable as
they may vary from organization to organization. They may include
information related to authorization, compliance requirements,
chains of delegation, and other domain-specific concerns.
* *Dynamic Management of Authorization Information:* The system must
allow creation, removal, updating, and deletion of authorization
information for agents, as agents can be highly dynamic.
* *Security and Privacy:* Ensuring secure and private sharing of
authorization information across domains.
* *Compliance and Auditability:* Support for compliance with
regulatory standards and auditability of authorization exchanges.
6. Solution Approaches
6.1. Solution Approach 1: Dynamic Client Registration (RFC 7591)
*Description:* Dynamic Client Registration as outlined in [RFC7591]
allows clients to register with an AS dynamically, facilitating the
management of client credentials and metadata.
*Discussion:*
Diaconu, et al. Expires 5 February 2027 [Page 8]
Internet-Draft AuthZ Sharing for Agents August 2026
+==================+===============================+================+
| Requirement | Met or Partially Met | Not Met |
+==================+===============================+================+
| Dynamic Identity | Met | |
| for Agents and | | |
| MCP Servers | | |
+------------------+-------------------------------+----------------+
| Interoperability | Partially Met (Granted by | |
| Across Domains | the Dynamic Registration, | |
| | however no common ground | |
| | between AS) | |
+------------------+-------------------------------+----------------+
| Flexible | | Not Met |
| Definition of | | (OAuth2 claims |
| Claims | | only) |
+------------------+-------------------------------+----------------+
| Dynamic | | Not Met |
| Management of | | (Delete or |
| Authorization | | Update not |
| Information | | supported) |
+------------------+-------------------------------+----------------+
| Security and | | Not Met |
| Privacy | | (Claims are |
| | | shared but no |
| | | common schema) |
+------------------+-------------------------------+----------------+
| Compliance and | Partially Met (Claims are | |
| Auditability | shared, APIs are auditable, | |
| | but no regulatory standards | |
| | are defined for the schema) | |
+------------------+-------------------------------+----------------+
Table 1
6.2. Solution Approach 2: SCIM extensions
[I-D.abbey-scim-agent-extension] proposes extending the SCIM (System
for Cross-Domain Identity Management) protocol to standardize the
provisioning, management, and governance of AI agents and other
digital workers.
[I-D.wahl-scim-agent-schema] is a companion document to the draft-
abbey-scim-agent-extension. Its purpose is to define the specific
SCIM schema and attributes required to represent AI agents (digital
workers) and agentic applications within the SCIM framework.
*Description:* Provision Agents / MCP Servers through a SCIM
extension.
Diaconu, et al. Expires 5 February 2027 [Page 9]
Internet-Draft AuthZ Sharing for Agents August 2026
*Discussion:*
+==================+======================================+=====+
| Requirement | Met or Partially Met | Not |
| | | Met |
+==================+======================================+=====+
| Dynamic Identity | Partially Met (SCIM support is | |
| for Agents and | limited and with constraints, | |
| MCP Servers | example for Azure: “Subsequent syncs | |
| | are triggered every 20-40 minutes”.) | |
+------------------+--------------------------------------+-----+
| Interoperability | Partially Met (SCIM is supported and | |
| Across Domains | schema is well defined) | |
+------------------+--------------------------------------+-----+
| Flexible | Met (Defined by the schema) | |
| Definition of | | |
| Claims | | |
+------------------+--------------------------------------+-----+
| Dynamic | Partially Met (SCIM support is | |
| Management of | limited and with constraints, | |
| Authorization | example for Azure: “Subsequent syncs | |
| Information | are triggered every 20-40 minutes”.) | |
+------------------+--------------------------------------+-----+
| Security and | Partially Met (A schema is defined | |
| Privacy | but Selective Disclosure not | |
| | supported) | |
+------------------+--------------------------------------+-----+
| Compliance and | Partially Met (Claims are shared, | |
| Auditability | APIs are auditable, but no | |
| | regulatory standards are defined for | |
| | the schema) | |
+------------------+--------------------------------------+-----+
Table 2
6.3. Solution Approach 3: Client-ID Metadata
*Description:* Client ID Metadata
[I-D.ietf-oauth-client-id-metadata-document] is a method for OAuth
clients to identify themselves using a URL, which points to a JSON
file containing their OAuth metadata. Instead of requiring pre-
registration, an authorization server can fetch this JSON document at
the client's provided URL to provision the identity.
*Discussion:*
Diaconu, et al. Expires 5 February 2027 [Page 10]
Internet-Draft AuthZ Sharing for Agents August 2026
+==================+==========================+=====================+
| Requirement | Met or Partially Met | Not Met |
+==================+==========================+=====================+
| Dynamic Identity | Met | |
| for Agents and | | |
| MCP Servers | | |
+------------------+--------------------------+---------------------+
| Interoperability | Met | |
| Across Domains | | |
+------------------+--------------------------+---------------------+
| Flexible | | Not Met* |
| Definition of | | (client_id is |
| Claims | | common, all the |
| | | rest is limited |
| | | to OAuth2 claims) |
+------------------+--------------------------+---------------------+
| Dynamic | Met | |
| Management of | | |
| Authorization | | |
| Information | | |
+------------------+--------------------------+---------------------+
| Security and | Partially Met** (A | |
| Privacy | schema is defined but | |
| | Selective Disclosure not | |
| | supported) | |
+------------------+--------------------------+---------------------+
| Compliance and | Partially Met** (Claims | |
| Auditability | are shared, APIs are | |
| | auditable, but no | |
| | regulatory standards are | |
| | defined for the schema) | |
+------------------+--------------------------+---------------------+
Table 3
**Flexible Definition of Claims:* The OAuth claims in the draft
follow the claims exposed and defined by IANA OAuth Parameters.
Hence, the metadata fields are limited to a fixed set of claims.
This makes it difficult to convey richer features about the client,
including provenance details, compliance attestations, or contextual
trust scores without introducing vendor-specific extensions, thereby
reducing portability and interoperability.
Diaconu, et al. Expires 5 February 2027 [Page 11]
Internet-Draft AuthZ Sharing for Agents August 2026
***Security and Privacy, Compliance and Auditability:* All metadata
is published to a publicly accessible endpoint. There is no native
ability to keep certain attributes private, apply selective
disclosure, or restrict visibility based on trust relationships.
Sensitive operational data or compliance-related data must be handled
outside the metadata framework, leading to fragmented trust models.
There is no mechanism for revocation and expiration.
6.4. Solution Approach 4: Client-ID Metadata + W3C Verifiable
Credentials Extension
Agent (Client) AuthZ Server (AS) Metadata Endpoint
| | |
| 1. Authorization Request | |
| (client_id = URL) | |
|--------------------------->| |
| | |
| | 2. HTTP GET (URL) |
| |--------------------->|
| | |
| | 3. Returns Metadata |
| | (JWKS + "vc+jwt") |
| |<---------------------|
| | |
| | 4. Validate Metadata |
| | & Verify VC Signature (JWKS)
| | |
Figure 1: Client-ID Metadata with VC Verification Flow
*Description:* The proposed solution is based on Solution 3, but
enhances the supported claims with a new claim, "vc+jwt", based on
the Verifiable Credentials Data Model 2.0 from W3C.
vc+jwt A standard method used in decentralized identity to package
and secure a digital credential. The Verifiable Credential (VC),
the actual data proving a fact (e.g., identity or degree), is
encapsulated within a JSON Web Token (JWT), which provides a
cryptographic signature from the issuer. This signature allows
any third party (the Verifier) to instantly confirm the
credential's authenticity and integrity. Modern formats like SD-
JWT VC further enhance this by enabling the holder to share only
specific parts of the credential (Selective Disclosure) to protect
privacy.
*Discussion:*
Diaconu, et al. Expires 5 February 2027 [Page 12]
Internet-Draft AuthZ Sharing for Agents August 2026
+===========================+======================+=========+
| Requirement | Met or Partially Met | Not Met |
+===========================+======================+=========+
| Dynamic Identity for | Met | |
| Agents and MCP Servers | | |
+---------------------------+----------------------+---------+
| Interoperability Across | Met (1) | |
| Domains | | |
+---------------------------+----------------------+---------+
| Flexible Definition of | Met (2) | |
| Claims | | |
+---------------------------+----------------------+---------+
| Dynamic Management of | Met | |
| Authorization Information | | |
+---------------------------+----------------------+---------+
| Security and Privacy | Met (3) | |
+---------------------------+----------------------+---------+
| Compliance and | Met (4) | |
| Auditability | | |
+---------------------------+----------------------+---------+
Table 4
*Detailed explanations:*
The W3C Verifiable Credentials Data Model 2.0 addresses the
shortcomings of the previous Solution 3, by introducing a
cryptographically verifiable and standards-based way to assert
identities, capabilities, and compliance attestations. It supports
selective disclosure to protect sensitive information, enables time-
bound and revocable authorizations, and ensures provenance tracking
for audit and regulatory compliance. They are part of a broader
decentralized identity (DID) specification.
Using the W3C Verifiable Credentials Data Model 2.0 for Agents, MCP
Clients, and MCP Servers provides a standardized, cryptographically
secure way to establish trust, delegate authority, and ensure
interoperability across different systems.
It enables Agents, MCP Clients, and MCP Servers to prove, among other
things, their identities, identity issuers and provenance, supported
skills and permitted actions through verifiable proofs, including
support for fine-grained and time-bound access control, while
maintaining transparency enabling audit trails for compliance.
Additionally, it enhances privacy through selective disclosure and
privacy-preserving proofs (e.g., allowing Agents to prove skills and
authorized actions without exposing unnecessary details).
Diaconu, et al. Expires 5 February 2027 [Page 13]
Internet-Draft AuthZ Sharing for Agents August 2026
The Verifiable Credentials Data Model 2.0 is a W3C standard that fits
the needs expressed above:
*(1) Enhanced Interoperability:* VCDM 2.0 provides a standardized,
extensible way to express identities, capabilities, and compliance
data across different systems. Its use of DIDs and schema-governed
claims ensures that Agents, MCP Clients, and MCP Servers can verify
and exchange trust information, enabling consistent interoperability
across domains and platforms.
*(2) Flexible Definition of Claims:* VCDM 2.0 allows arbitrary,
schema-governed claims that can represent complex concepts such as
provenance, software supply-chain attestations (e.g., SLSA), security
posture, audit certifications (SOC2, ISO-27001), or dynamic trust
signals. These claims can be extended without breaking
interoperability, thanks to widely adopted JSON-LD and schema
registries.
*(3) Security and Privacy:* Credentials are signed using verifiable
cryptographic proofs (e.g., JSON Web Signatures, Data Integrity
proofs). This ensures that Agents, MCP clients, and MCP servers can
verify the authenticity of claims without relying solely on HTTPS
endpoints or centralized registries. Through techniques like BBS+
signatures, holders can disclose only the subset of claims required
for a given authorization flow. This is essential for scenarios
where Agents must prove capabilities (e.g., "I'm allowed to execute
this skill") without revealing unnecessary or sensitive identity
attributes.
*(4) Compliance and Auditability:* VCDM 2.0 enables cryptographically
verifiable audit trails by binding each credential to an issuer,
timestamp, and revocation status. Compliance attestations can be
embedded directly in credentials, and real-time revocation checks
ensure they remain valid. This provides trustworthy provenance,
regulatory-grade accountability, and reliable lifecycle tracking
across distributed systems.
6.4.1. Delegation Semantics for Cross-Domain Multi-Agent Workflows
Multi-agent systems frequently involve chains of delegation where
Agent A invokes Agent B, which may invoke Agent C, potentially
spanning multiple administrative domains. This section defines
authorization semantics for such delegation chains, addressing the
novel challenges of cross-domain delegation.
Diaconu, et al. Expires 5 February 2027 [Page 14]
Internet-Draft AuthZ Sharing for Agents August 2026
Humans rarely delegate authority through multiple levels across
organizational boundaries. Agents routinely do so. Existing
delegation mechanisms ([RFC8693] Token Exchange 'act' claims) assume
single-domain operation and do not address cross-domain VC-based
delegation with verifiable accountability chains.
6.4.1.1. Delegation Models
This specification supports two delegation models:
Direct Invocation Agent A directly invokes MCP Server M using A's
own credentials. No delegation occurs; authorization is based
solely on A's VC.
Delegated Invocation (Cross-Domain) Agent A in Domain X invokes
Agent B in Domain Y to perform a task. B acts on A's behalf (and
transitively, on behalf of A's originating principal) when
accessing resources. The authorization decision considers both
A's delegation grant and B's own credentials, applying Domain Y's
policies.
Domain X | Domain Y
|
+-----------+ +---------+ | +---------+ +--------------+
| Principal | | Agent A | | | Agent B | | MCP Server M |
| P | | | | | | | |
+-----------+ +---------+ | +---------+ +--------------+
| | | | |
| 1. Task | | | |
|------------->| | | |
| | | | |
| | 2. Delegate + VC(A)| |
| |------------|------>| |
| | | | |
| | | | 3. Request |
| | | | + VC(B) |
| | | | + Deleg(A) |
| | | |-------------->|
| | | | |
| | | | 4. Verify chain
| | | | 5. Apply local policy
| | | | 6. Authorize
Figure 2: Cross-Domain Delegation Flow
Diaconu, et al. Expires 5 February 2027 [Page 15]
Internet-Draft AuthZ Sharing for Agents August 2026
6.4.1.2. Scope Derivation Rules
When Agent A delegates to Agent B (potentially across domains), B's
effective scope MUST be computed as the intersection of:
1. A's delegatable scope: The subset of A's permissions that A is
authorized to delegate
2. B's intrinsic scope: The permissions B holds in its own VC
3. Explicit delegation grant: What A actually delegated to B for
this invocation
4. Receiving domain policy: The maximum scope the receiving domain
permits for this cross-domain delegation
Effective_Scope(B) = A.delegatable_scope
INTERSECT B.intrinsic_scope
INTERSECT Delegation.granted_scope
INTERSECT Receiving_Domain_Policy
Figure 3: Scope Derivation Formula
This ensures:
* B cannot exceed A's authority (no privilege amplification)
* B cannot exceed its own authority (intrinsic limits apply)
* A can further restrict B for specific tasks (explicit grant)
* The receiving domain retains sovereignty over its resources (local
policy)
Implementations MUST enforce monotonic scope narrowing: at each
delegation step, effective scope can only decrease or remain the
same, never increase.
This intersection semantics aligns with capability-based security
principles (see: Mark Miller's Principle of Least Authority, Google
Macaroons, Biscuit authorization tokens) and extends [RFC8693] Token
Exchange delegation semantics to cross-domain VC-based scenarios.
Diaconu, et al. Expires 5 February 2027 [Page 16]
Internet-Draft AuthZ Sharing for Agents August 2026
6.4.1.3. Accountability Chain Construction
Each delegation step MUST produce a verifiable record enabling cross-
domain forensic reconstruction.To support revocation and scope-change
handling, delegation records SHOULD enable downstream verifiers to
identify and validate upstream delegation elements so that
authorization decisions do not depend on revoked or superseded
delegation claims. The delegation record MUST include:
+==================+=================+===========================+
| Field | Description | Cross-Domain Relevance |
+==================+=================+===========================+
| delegator_id | Agent A's id | Enables tracing to |
| | from its VC | originating domain |
+------------------+-----------------+---------------------------+
| delegator_domain | Domain that | Identifies trust |
| | issued A's VC | relationship to verify |
+------------------+-----------------+---------------------------+
| delegatee_id | Agent B's id | Identifies receiving |
| | from its VC | agent |
+------------------+-----------------+---------------------------+
| delegatee_domain | Domain that | Identifies receiving |
| | issued B's VC | domain |
+------------------+-----------------+---------------------------+
| timestamp | Time of | Temporal ordering for |
| | delegation | forensics |
+------------------+-----------------+---------------------------+
| granted_scope | Scopes | Audit of intended |
| | delegated | authorization |
+------------------+-----------------+---------------------------+
| expiration | Delegation | MUST NOT exceed |
| | validity period | delegator's VC expiration |
+------------------+-----------------+---------------------------+
| chain_hash | Cryptographic | Ensures chain integrity |
| | binding to | across domains |
| | prior chain | |
+------------------+-----------------+---------------------------+
Table 5: Delegation Record Fields
The complete accountability chain enables:
1. Cross-domain attribution: Determining which principal originated
a request that traversed multiple domains
2. Forensic reconstruction: Rebuilding the sequence of delegations
across domain boundaries
Diaconu, et al. Expires 5 February 2027 [Page 17]
Internet-Draft AuthZ Sharing for Agents August 2026
3. Coordinated revocation: Identifying downstream delegations in
other domains that must be invalidated
6.4.1.4. Delegation Depth Limits
Implementations SHOULD enforce maximum delegation depth. Cross-
domain delegations SHOULD count toward depth limits regardless of
whether they're same-domain or cross-domain.
Receiving domains MAY impose stricter depth limits than the
originating domain. When a delegation would exceed the receiving
domain's depth limit, the AS MUST reject the request with an error
indicating the depth violation.
6.4.1.5. Delegation Claims in VCs
To express delegation authority in VCs, the following claims are
defined for credentialSubject:
{
"credentialSubject": {
"id": "https://example.com/agents/agent-a",
"delegation": {
"permitted": true,
"maxDepth": 2,
"crossDomainDelegation": {
"permitted": true,
"allowedDomains": ["partner.example.org"],
"deniedDomains": ["competitor.example.com"]
},
"allowedDelegateeTypes": ["tool-agent", "workflow-agent"],
"scopeRestrictions": {
"nonDelegatable": ["admin:*", "pii:write"],
"crossDomainNonDelegatable": ["internal:*"]
}
}
}
}
Figure 4: Delegation Claims Example
delegation.permitted Boolean indicating whether this agent may
delegate. Default: false.
delegation.maxDepth Maximum additional delegation hops this agent
may initiate. Default: 0.
delegation.crossDomainDelegation.permitted Whether cross-domain
Diaconu, et al. Expires 5 February 2027 [Page 18]
Internet-Draft AuthZ Sharing for Agents August 2026
delegation is allowed at all.
delegation.crossDomainDelegation.allowedDomains Domains to which
delegation is permitted (wildcards allowed).
delegation.scopeRestrictions.crossDomainNonDelegatable Scopes that
may be delegated within the same domain but MUST NOT be delegated
across domain boundaries.
6.4.2. Agent Authorization Verifiable Credential Profile
This section defines a Verifiable Credential profile that enables
interoperable cross-domain agent authorization. The profile
specifies claims that Authorization Servers in different domains can
reliably interpret.
W3C VCDM 2.0 is intentionally flexible. For cross-domain
interoperability, domains must agree on claim semantics. This
profile provides that common language.
The claims in this profile are defined at the top level of the
credential subject. They can be carried as plain JWT claims for
direct identity presentation, or wrapped in a VC for cross-domain use
where selective disclosure, revocation, and issuer-independent
verification are required. This document specifies the claim
hierarchy, not an exhaustive set of nested fields, so that
implementations can adopt the profile without committing to a
specific serialization of every attribute.
6.4.2.1. Profile Objectives
The Agent Authorization VC Profile (AAVC) enables:
* Cross-domain interoperability: ASs in different domains can parse
and evaluate the same VC
* Semantic clarity: Claim meanings are defined, reducing policy skew
risk
* Extensibility: Organizations can add custom claims without
breaking base interoperability
* Selective disclosure compatibility: Claims are structured to
support SD-JWT VC presentation
Diaconu, et al. Expires 5 February 2027 [Page 19]
Internet-Draft AuthZ Sharing for Agents August 2026
6.4.2.2. Required Claims for Cross-Domain Interoperability
The credentialSubject MUST include these claims for a VC to be
recognized across domains:
id (required) Globally unique identifier for the agent. SHOULD be a
dereferenceable URI pointing to client-id metadata.
agentType (required) Classification of the agent. Receiving domains
use this to apply type-specific policies. Implementations MUST
support:
* tool-agent: Provides specific tool/skill capabilities
* orchestrator-agent: Coordinates other agents
* workflow-agent: Executes multi-step workflows
* system-agent: Long-running infrastructure agent
* ephemeral-agent: Short-lived, single-task
authorizedScopes (required) Authorization scopes this agent may
request. Receiving domains map these to local authorization
policies.
issuerDomain (required) Administrative domain of the credential
issuer. Receiving ASs use this to look up trust relationships and
policy mappings.
6.4.2.3. Recommended Claims for Production Deployments
dataSensitivityClearance (recommended) Maximum data sensitivity
level this agent may access. Standard values:
* public - Publicly available information
* internal - Organization-internal, non-sensitive
* confidential - Business-sensitive information
* restricted - Highly sensitive, need-to-know basis
* regulated - Subject to regulatory controls (PII, PHI, PCI)
complianceAttestations (recommended) Compliance certifications
relevant to cross-domain trust decisions. Should include
standard, scope, validUntil, and optionally certificationBody.
Diaconu, et al. Expires 5 February 2027 [Page 20]
Internet-Draft AuthZ Sharing for Agents August 2026
operationalConstraints (recommended) Runtime constraints that
receiving domains MAY enforce, including maxConcurrentSessions,
maxRequestsPerMinute, allowedTimeWindows, and geofence
restrictions.
delegation (recommended) Delegation permissions as defined in
Section 6.4.1.5.
6.4.2.4. Extension Mechanism
Organizations MAY extend the profile with additional claims by:
1. Defining a JSON-LD context document for the extension
2. Including the extension context URI in the VC's @context array
3. Adding extension claims under a namespace prefix
Implementations receiving VCs with unrecognized claims SHOULD:
* Ignore unknown claims (do not reject the VC)
* Log unrecognized claims for operational visibility
* NOT make authorization decisions based on claims they cannot
interpret
6.4.2.5. Interoperability Requirements
For cross-domain interoperability, implementations:
MUST:
* Support required claims (id, agentType, authorizedScopes,
issuerDomain)
* Recognize the AgentAuthorizationCredential type
* Verify the credential proof before processing claims
* Reject VCs missing required claims
SHOULD:
* Support recommended claims
* Implement selective disclosure for cross-domain presentations
Diaconu, et al. Expires 5 February 2027 [Page 21]
Internet-Draft AuthZ Sharing for Agents August 2026
* Maintain logs of cross-domain VC presentations
MAY:
* Define and process organization-specific extensions
* Implement additional validation beyond profile requirements
6.5. Relationship to JWT Profile Approaches
Other work defines JWT profiles with predefined claims for agent and
principal identity, for example a profile that carries agent, agent
platform, and human identity claims as typed JSON in a signed JWT
[I-D.skyfire-kyapayprofile]. That approach uses standard JWT claims
without a JSON-LD context or a Verifiable Credential proof structure.
A JWT profile of that kind fits direct identity presentation, where
an agent asserts its identity and its principal's identity to a
single service endpoint. Validation follows ordinary JWT processing
and no VC infrastructure is needed.
The VC-based approach in Solution Approach 4 targets cross-domain
authorization, where an Authorization Server in one domain evaluates
a credential issued in another domain without a direct trust
relationship to the issuer's token endpoint. The proof is bound to
the credential rather than to the transport or the issuing endpoint.
This allows selective disclosure, revocation, and verification by a
party that does not trust the issuer's infrastructure directly.
The approaches are complementary. The claim set defined by the Agent
Authorization VC Profile can be carried as plain JWT claims for
direct presentation, or wrapped in a VC for cross-domain use where
the additional properties are needed. An agent can hold both forms.
The choice depends on the deployment context described in Appendix A.
7. Example
This section provides illustrative examples of how Client-ID Metadata
can be extended with Verifiable Credentials for agent identity.
These examples demonstrate the recommended Approach 4 and show how
the concepts apply to scenarios similar to the travel booking use
case described earlier. These examples are non-normative and
intended to demonstrate the concepts discussed in this document.
7.1. Client-ID Metadata Example
The following example shows OAuth client metadata that includes a
Verifiable Credential in the "vc+jwt" field:
Diaconu, et al. Expires 5 February 2027 [Page 22]
Internet-Draft AuthZ Sharing for Agents August 2026
{
"client_id": "https://agents.example.com/agent-001/metadata.json",
"client_name": "Customer Service Agent 001",
"jwks_uri": "https://agents.example.com/agent-001/jwks.json",
"token_endpoint_auth_method": "private_key_jwt",
"grant_types": ["client_credentials"],
"scope": "read:orders write:tickets",
"vc+jwt": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJAY29udGV4dCI6W..."
}
The "vc+jwt" field contains a JWT-encoded Verifiable Credential. The
actual JWT would be significantly longer and contain the complete
credential structure shown in the next subsection.
7.2. Verifiable Credential Example
The following example shows the decoded structure of a Verifiable
Credential for an agent (before JWT encoding):
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://example.org/agent-credentials/v1"
],
"type": ["VerifiableCredential", "AgentIdentityCredential"],
"issuer": "did:web:issuer.example.com",
"issuanceDate": "2025-01-15T10:30:00Z",
"expirationDate": "2026-01-15T10:30:00Z",
"credentialSubject": {
"id": "https://agents.example.com/agent-001/metadata.json",
"agentName": "Customer Service Agent 001",
"agentVersion": "2.1.0",
"agentType": "customer-service",
"owner": "did:web:example.com",
"authorizedCapabilities": [
"order-lookup",
"ticket-creation",
"customer-notification"
],
"delegatedCredentials":[
{
"id": "https://agents.partner.com/agent-111/metadata.json",
"agentName":"Sec Agent 111",
"delegatedBy":"https://agents.example.com/agent-001/metadata.json",
"delegationChain": [
"urn:uuid:*****",
"urn:uuid:***"
],
Diaconu, et al. Expires 5 February 2027 [Page 23]
Internet-Draft AuthZ Sharing for Agents August 2026
"scope": "read:sec-remediate:isolations",
"authorizedCapabilities": [
"enrichment",
"isolation-request"
],
"constraints": {
"dpopNonceRequired": true
}
}
],
"complianceFrameworks": ["SOC2-TypeII", "ISO-27001"],
"delegationLevel": 1,
"maxDelegationDepth": 2
},
"credentialStatus": {
"id": "https://issuer.example.com/status/2024/12345",
"type": "StatusList2021Entry",
"statusPurpose": "revocation",
"statusListIndex": "12345",
"statusListCredential": "https://issuer.example.com/status/2024"
}
}
Note: The actual credential would include a "proof" section with
cryptographic signatures. The proof section is omitted here for
clarity, as it would add significant length to the example. The
proof structure varies depending on the signature suite used (e.g.,
Ed25519Signature2020, JsonWebSignature2020).
8. Related Work
Several efforts address adjacent parts of the agent authorization
problem.
[I-D.klrc-aiagent-auth] describes agent authentication and
authorization using a WIMSE-based architecture and OAuth 2.0. It
works at the protocol flow layer, covering identity chaining and
token exchange. This document works at the credential layer,
covering the claims carried in client-id metadata. The two address
different layers of the same problem.
[I-D.skyfire-kyapayprofile] defines a JWT profile for agent identity
and payment tokens. The relationship to the VC-based approach is
discussed in Section 6.5.
Academic analysis of agent and tool-protocol security supports the
threat categories in this document, including formal study of
protocol-level authentication gaps [BreakingTheProtocol] and
Diaconu, et al. Expires 5 February 2027 [Page 24]
Internet-Draft AuthZ Sharing for Agents August 2026
measurement of authentication weaknesses in deployed servers
[MCP.AuthMeasurement]. Work on authenticated delegation for agents
extends OAuth and OpenID Connect with agent-specific credentials and
auditable delegation [AuthDelegation].
Work in the Coalition for Secure AI (CoSAI) on agentic identity and
access management, and on secure design patterns for MCP-based
systems, provides the enterprise framing within which the protocol
mechanisms in this document operate. See [CoSAI.AgenticIAM] and
[CoSAI.MCPSecureToolDesign].
9. Security Considerations
9.1. Security Considerations
This section addresses security considerations specific to cross-
domain authorization information sharing. Implementations MUST also
follow security guidance in [RFC6819], [W3C.VCDM2.0], and
[I-D.ietf-oauth-client-id-metadata-document].
9.1.1. Threat Model for Cross-Domain Authorization Sharing
This section defines threats specific to sharing authorization
information across administrative domain boundaries. General OAuth
and VC security threats are addressed in [RFC6819] and [W3C.VCDM2.0];
this section focuses on threats that emerge or are amplified when
credentials cross domain boundaries.
9.1.1.1. Protected Assets in Cross-Domain Scenarios
Beyond standard authorization assets, cross-domain sharing introduces
additional assets requiring protection:
Cross-Domain Trust Relationships The established trust between
domains that enables agents to operate across organizational
boundaries. Compromise affects all agents relying on that trust
relationship.
Shared Authorization Semantics The agreed-upon meaning of claims,
scopes, and compliance attestations between domains. Semantic
drift or manipulation can cause authorization decisions that
violate one or both domains' policies.
Delegation Chains Spanning Domains When agent A in Domain X
delegates to agent B in Domain Y, the chain itself becomes an
asset requiring integrity protection across trust boundaries.
Diaconu, et al. Expires 5 February 2027 [Page 25]
Internet-Draft AuthZ Sharing for Agents August 2026
9.1.1.2. Cross-Domain Specific Threat Actors
Rogue Domain An entire domain that participates in the trust
federation but issues fraudulent VCs or makes incorrect
authorization decisions, either through compromise or malicious
operation. Unlike a single rogue IdP, a rogue domain may control
IdP, AS, and metadata endpoints coherently.
Cross-Domain Insider An administrator with legitimate access in
Domain A who abuses cross-domain trust relationships to gain
unauthorized access to Domain B's resources.
9.1.1.3. Cross-Domain Attack Categories
9.1.1.3.1. Trust Anchor Attacks
Metadata Endpoint Compromise An attacker gains control of the URL
hosting an agent's client-id metadata document and substitutes
malicious metadata or VCs. Because the metadata URL is the trust
anchor for cross-domain identity, compromise enables complete
identity takeover across all trusting domains.
Cross-domain amplification: In single-domain scenarios, the AS
typically has out-of-band trust with clients. In cross-domain
scenarios, the metadata endpoint IS the sole trust anchor, and
there's no fallback.
Metadata Poisoning Injection of false claims into legitimate
metadata documents through supply chain attacks, DNS hijacking, or
exploitation of hosting infrastructure.
Cross-domain amplification: Poisoned metadata propagates trust
violations to all domains that fetch and cache the metadata.
9.1.1.3.2. Semantic Attacks
Policy Skew Exploitation An agent authorized under Domain A's
policies operates in Domain B where different security policies
apply. The agent performs actions that are within Domain A's
authorized scope but violate Domain B's policies.
Claim Semantic Drift Domains interpret the same claim differently,
leading to authorization decisions that neither domain intended.
Compliance Attestation Mismatch Compliance attestations (SOC2, ISO-
27001, GDPR) in VCs are accepted at face value without verifying
that the issuing domain's certification scope covers the receiving
domain's requirements.
Diaconu, et al. Expires 5 February 2027 [Page 26]
Internet-Draft AuthZ Sharing for Agents August 2026
9.1.1.3.3. Delegation Attacks Across Domains
Cross-Domain Privilege Amplification In multi-hop delegation (A to B
to C) where agents belong to different domains, downstream agents
in permissive domains accumulate effective permissions that exceed
what the originating principal intended.
Accountability Chain Breakage Delegation chains that cross domain
boundaries lose forensic continuity. When incidents occur,
attribution cannot be reconstructed because each domain only has
partial visibility.
Confused Deputy Across Trust Boundaries An attacker in Domain A
tricks a trusted agent in Domain B into performing actions on
their behalf that the attacker couldn't perform directly,
exploiting the cross-domain trust relationship. See [Hardy1988].
9.1.1.3.4. Cross-Domain Lateral Movement
Using legitimate cross-domain authorization to pivot from a
compromised position in Domain A to resources in Domain B that would
not otherwise be accessible. An attacker compromises a low-privilege
agent in Domain A. That agent has cross-domain authorization to
Domain B. The attacker uses the agent's credentials to establish a
foothold in Domain B, then escalates within Domain B.
9.1.1.3.5. Correlation and Privacy Attacks
Linking agent activities across domains using stable identifiers in
VCs to build profiles of organizational operations, potentially
revealing sensitive business processes or security postures.
Cross-domain amplification: In single-domain scenarios, the domain
controls what's logged. In cross-domain scenarios, each domain
receiving the VC can correlate independently, and the agent's home
domain cannot prevent this.
9.1.1.3.6. Tool Registry Poisoning
Agents discover available tools by querying a registry or directory.
Any dynamic tool discovery mechanism is therefore an authorization
input. If a registry entry is mutable, unsigned, stale, or
redirected, the Authorization Server may end up authorizing the wrong
executable capability. An attacker who can write to the registry, or
redirect the endpoints it points to, can substitute malicious tool
definitions or reroute tool calls to an attacker-controlled server.
Most agent frameworks do not verify tool integrity at invocation
time, so once an entry is in the registry the agent treats it as
Diaconu, et al. Expires 5 February 2027 [Page 27]
Internet-Draft AuthZ Sharing for Agents August 2026
trusted and the redirection is not visible to the caller.
Registry Write Compromise Direct modification of tool entries
through the registry database or its management API.
Endpoint Redirection Repointing a tool's endpoint URL to an
attacker-controlled host, for example through DNS hijacking or a
stale entry whose original host is no longer controlled by the
tool provider.
Supply Chain Injection Inserting malicious tools into the registry
through a compromised build or publishing pipeline.
Cross-domain amplification: a registry shared across domains
propagates a poisoned entry to every domain that resolves tools
through it. A single write compromise affects all consumers.
Mitigation binds the tool identity to its implementation so the
Authorization Server can verify it. A vc+jwt credential can carry a
cryptographic fingerprint of the tool, for example a SHA-256 hash of
the tool definition or a subresource integrity hash of the endpoint
contract, which the verifier checks before authorizing the call. The
endpoint's TLS certificate is verified against an expected value at
invocation time, and registry entries are revalidated against a
known-good baseline on a schedule. This attack class and its
mitigations are discussed in recent work on tool squatting and tool
poisoning in agent tool registries [ToolSquatting] [ETDI].
9.1.1.4. Empirical Validation of the Threat Model
Between February and April 2026, the threat categories above were
exercised by public incidents and measurement studies. This section
maps observed events to the threat model. The intent is to show that
the threats produce real consequences, not to attribute specific
products.
9.1.1.4.1. Autonomous Agent Exploitation of CI/CD Pipelines
An autonomous agent ran a multi-day campaign against continuous
integration pipelines across repositories at several technology
companies. It obtained remote code execution in multiple targets,
using a different technique for each pipeline configuration. The
agent held valid credentials throughout. The failure was not in
identity verification but in the absence of intent validation and
scope enforcement. One target was not compromised because a code
review step detected the injected instructions and refused to act on
them.
Diaconu, et al. Expires 5 February 2027 [Page 28]
Internet-Draft AuthZ Sharing for Agents August 2026
Maps to: confused deputy across trust boundaries (Section 9.1.1.3.3)
and cross-domain lateral movement (Section 9.1.1.3.4). Valid
credentials with invalid intent is the core pattern. The vc+jwt
approach in this document carries scope and operational constraints
that an Authorization Server can check against the requested action,
which a bare credential check cannot.
9.1.1.4.2. Enterprise AI Platform Breach
An offensive agent reached the production database of an internal AI
platform in under two hours, without credentials, by finding
unauthenticated API endpoints and a SQL injection path. The same
access allowed modification of the prompts that governed the
platform's behavior.
Maps to: metadata endpoint compromise (Section 9.1.1.3.1). The
platforms that host and coordinate agents are themselves
authorization targets and need the same rigor as the agents they run.
The ability to alter governing prompts through the same access is a
trust poisoning path that authorization controls on the platform
itself would constrain.
9.1.1.4.3. Optional Authentication in Tool Servers
Public vulnerability records in this period described missing
authentication for critical functions in deployed MCP server
implementations, including a server-side request forgery path
reachable without an authorization header and a critical-function
authentication gap that allowed an unauthorized network attacker to
act on the server [CVE-2026-32211]. A measurement study of remote
MCP servers in the same period found unauthenticated tool exposure to
be widespread [MCP.AuthMeasurement]. The common root cause is that
the protocol treats authentication as optional and leaves it to each
implementer.
Maps to: credential forgery (Section 9.1.1.3.1) and the broader gap
this document addresses. Making agent identity a required part of
the metadata that an Authorization Server fetches, rather than an
optional implementation choice, removes the class of failure that
comes from optional authentication.
9.1.1.4.4. Silent Trust Boundary Failure in an Agent Framework
An agent orchestration framework was found to allow a chain from
prompt injection to sandbox escape to remote code execution. The
sandbox fell back to an unsandboxed mode when its container runtime
was unavailable, without signaling the change, so the agent and the
orchestrator both assumed isolation that was not in effect.
Diaconu, et al. Expires 5 February 2027 [Page 29]
Internet-Draft AuthZ Sharing for Agents August 2026
Maps to: delegation attacks across domains (Section 9.1.1.3.3). A
verifiable assertion about an agent's execution environment, carried
in its credential, lets an Authorization Server decide based on the
actual enforcement state rather than an assumption about the
framework.
9.1.1.5. Trust Establishment Between Domains
9.1.1.5.1. Domain Trust Lists
Before accepting VCs from another domain, an Authorization Server
MUST verify that the issuing domain is in an explicitly configured
trust list. Implementations MUST NOT implicitly trust domains based
solely on successful cryptographic verification of the VC.
Trust list entries SHOULD include:
* Domain identifier (issuerDomain claim value)
* Accepted VC types from that domain
* Scope of trust (which local resources may be accessed)
* Expiration or review date for the trust relationship
9.1.1.5.2. Cross-Domain Policy Mapping
Implementations MUST NOT assume semantic equivalence of claims across
domains. Before accepting a VC from another domain, the AS SHOULD
verify:
1. Explicit mapping exists between the foreign domain's claim
semantics and local policy requirements
2. Compliance attestations in the VC meet local regulatory
requirements (not just the issuing domain's)
3. Scope values have been mapped to local authorization semantics
9.1.1.5.3. Trust Relationship Lifecycle
Cross-domain trust relationships MUST have defined lifecycles:
* Periodic review and re-validation
* Documented procedures for trust relationship termination
Diaconu, et al. Expires 5 February 2027 [Page 30]
Internet-Draft AuthZ Sharing for Agents August 2026
* Immediate revocation capability when a trusted domain is
compromised
* Notification mechanisms between domains for security events
9.1.1.6. Metadata Endpoint Security for Cross-Domain Trust
Because the client-id metadata endpoint is the sole trust anchor for
cross-domain agent identity, it requires enhanced protection beyond
typical endpoint security.
9.1.1.6.1. Endpoint Integrity Beyond Transport
Metadata documents SHOULD be signed independently of the transport
layer, allowing verification even if TLS is compromised or if the
document is cached by intermediaries.
9.1.1.6.2. Change Detection for Cached Metadata
Authorization Servers SHOULD:
* Cache fetched metadata documents with appropriate TTLs
* Detect and alert on unexpected changes to critical fields
(jwks_uri, vc+jwt, token_endpoint_auth_method)
* Implement anomaly detection for metadata that changes more
frequently than expected
9.1.1.6.3. Cross-Domain Availability Dependencies
When metadata endpoints are unavailable, cross-domain authorization
fails. Implementations SHOULD:
* Cache validated metadata with TTLs appropriate to the sensitivity
of protected resources
* Implement circuit breakers to prevent cascading failures
* Define graceful degradation policies
9.1.1.7. Delegation Security Across Domain Boundaries
9.1.1.7.1. Domain Boundary Checkpoints
When a delegation chain crosses a domain boundary, the receiving
domain's AS MUST:
Diaconu, et al. Expires 5 February 2027 [Page 31]
Internet-Draft AuthZ Sharing for Agents August 2026
* Fully verify the upstream delegation chain before accepting
* Apply local policy to the delegation
* Log the domain boundary crossing for audit purposes
Receiving domains SHOULD consider the status of delegated credentials
and, where status information is available, avoid making
authorization decisions that rely on revoked,suspended, or suspended
delegation chain elements, according to local policy.
Deployments concerned with stale delgations MAY apply bounded caching
and periodic revalidation of delegation status appropriate to the
sensitivity of protected resources.
9.1.1.7.2. Monotonic Scope Narrowing Across Domains
Implementations MUST enforce that effective scope can only decrease
(or remain the same) at each delegation step, including when crossing
domain boundaries. The receiving domain MUST apply its local policy
as an additional constraint on effective scope.
9.1.1.7.3. Accountability Chain Preservation
Delegation chains spanning domains MUST maintain cryptographically
verifiable accountability. Each domain SHOULD:
* Preserve the incoming delegation chain in its audit logs
* Add its own delegation record when extending the chain
* Provide APIs for authorized forensic queries from upstream domains
9.1.1.8. Privacy Considerations for Cross-Domain Sharing
9.1.1.8.1. Selective Disclosure for Cross-Domain Presentations
Agents presenting VCs across domain boundaries SHOULD use selective
disclosure mechanisms (SD-JWT VC, BBS+ signatures) to reveal only
claims necessary for the specific cross-domain authorization request.
9.1.1.8.2. Correlation Risk Assessment
Organizations SHOULD assess cross-domain correlation risks before
establishing trust relationships, including whether agent identifiers
enable activity tracking by foreign domains.
Diaconu, et al. Expires 5 February 2027 [Page 32]
Internet-Draft AuthZ Sharing for Agents August 2026
10. IANA Considerations
This document introduces a new OAuth client metadata parameter
"vc+jwt" as described in the Solution Analysis section (Approach 4).
If this approach is standardized, the following registration would be
required:
* *Registry:* IANA [`OAuth Dynamic Client Registration
Metadata`](https://www.iana.org/assignments/oauth-parameters/
oauth-parameters.xhtml#client-metadata) registry
* *Client Metadata Name:* vc+jwt
* *Client Metadata Description:* JWT-encoded Verifiable Credential
* *Change Controller:* TBD
* *Reference:* https://www.w3.org/TR/vc-data-model-2.0
This informational document does not make a formal request for IANA
registration at this time. Registration would be appropriate if this
approach is adopted and progresses to a standards track
specification.
11. References
11.1. Informative References
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[I-D.abbey-scim-agent-extension]
Abbey, J., "SCIM Extensions for Agents", 2025.
[I-D.wahl-scim-agent-schema]
Wahl, M., "SCIM Schema for Agents", 2025.
[I-D.ietf-oauth-client-id-metadata-document]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Client
Identity Metadata Document", 2025.
[W3C.VCDM2.0]
W3C, "Verifiable Credentials Data Model v2.0", 2024,
<https://www.w3.org/TR/vc-data-model-2.0/>.
Diaconu, et al. Expires 5 February 2027 [Page 33]
Internet-Draft AuthZ Sharing for Agents August 2026
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", January 2020,
<https://www.rfc-editor.org/info/rfc8693>.
[Hardy1988]
Hardy, N., "The Confused Deputy: (or why capabilities
might have been invented)", ACM SIGOPS Operating Systems
Review Volume 22, Issue 4, 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[I-D.ietf-oauth-selective-disclosure-jwt]
Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JWTs (SD-JWT)", 2024.
[I-D.klrc-aiagent-auth]
Kasselman, P., "AI Agent Authentication and
Authorization", 2026.
[I-D.skyfire-kyapayprofile]
Agarwal, A. and M. Jones, "KYAPay Profile", March 2026.
[NIST.NCCoE.AgentIdentity]
National Cybersecurity Center of Excellence, NIST,
"Accelerating the Adoption of Software and Artificial
Intelligence Agent Identity and Authorization", February
2026, <https://www.nccoe.nist.gov/news-insights/new-
concept-paper-identity-and-authority-software-agents>.
Diaconu, et al. Expires 5 February 2027 [Page 34]
Internet-Draft AuthZ Sharing for Agents August 2026
[MCP.AuthMeasurement]
Zhou, H., "A First Measurement Study on Authentication
Security in Real-World Remote MCP Servers", 2026,
<https://arxiv.org/abs/2605.22333>.
[BreakingTheProtocol]
Maloyan, N. and D. Namiot, "Breaking the Protocol:
Security Analysis of the Model Context Protocol
Specification", 2026, <https://arxiv.org/abs/2601.17549>.
[AuthDelegation]
South, T., "Authenticated Delegation and Authorized AI
Agents", 2025, <https://arxiv.org/abs/2501.09674>.
[ToolSquatting]
Narajala, V.S., "Securing GenAI Multi-Agent Systems
Against Tool Squatting: A Zero Trust Registry-Based
Approach", 2025.
[ETDI] Bhatt, M., "ETDI: Mitigating Tool Squatting and Rug Pull
Attacks in MCP Using OAuth-Enhanced Tool Definitions",
2025.
[CVE-2026-32211]
National Vulnerability Database, NIST, "CVE-2026-32211:
Missing Authentication for Critical Function", 2026,
<https://nvd.nist.gov/vuln/detail/CVE-2026-32211>.
[CoSAI.AgenticIAM]
Coalition for Secure AI (CoSAI), OASIS, "Agentic Identity
and Access Management", March 2026,
<https://www.coalitionforsecureai.org/>.
[CoSAI.MCPSecureToolDesign]
Coalition for Secure AI (CoSAI), OASIS, "MCP Secure Tool
Design", 2026, <https://www.coalitionforsecureai.org/>.
Appendix A. Mapping Mechanisms to Deployment Contexts
The mechanisms in this document apply with different rigor depending
on the deployment. This appendix is informative. Not every
deployment needs every mechanism. The intent is to identify a
minimum set of controls for a given risk profile and a path from what
is deployable today to what is needed for regulated cross-domain
operation.
Level 1, Sandbox or Development Isolated environments with no
Diaconu, et al. Expires 5 February 2027 [Page 35]
Internet-Draft AuthZ Sharing for Agents August 2026
production data and no cross-domain connectivity. Standard OAuth2
with local scope management. The cross-domain mechanisms in this
document are not required.
Level 2, Internal and Non-Sensitive A single administrative domain
accessing non-sensitive resources. Client-ID Metadata without VCs
(Solution Approach 3) can be sufficient. Basic OAuth scope
management applies. Delegation is limited to direct invocation.
This level is supportable on existing IdP and Authorization Server
infrastructure without new components.
Level 3, Production and Cross-Domain Operation across domains on
business-sensitive resources. Client-ID Metadata with Verifiable
Credentials (Solution Approach 4). The vc+jwt claim carries
compliance attestations and operational constraints. Delegation
with scope intersection applies. Sender-constrained tokens are
recommended. Credential lifetimes are bounded and revocation is
checked. This level needs VC issuance but not hardware-attested
key storage.
Level 4, Regulated and High-Assurance Regulated data or irreversible
operations across domains. All Level 3 mechanisms apply, plus
hardware-attested key storage, cryptographic binding between agent
identity and execution environment, and re-authorization at trust
boundary crossings. Audit logging supports cross-domain
forensics. Selective disclosure is used to limit data exposure in
cross-domain presentations.
The expected path is to start at Level 2 and add VCs (moving to Level
3) when cross-domain requirements appear, without replacing the
underlying authorization infrastructure.
Authors' Addresses
Jean Diaconu
Cisco Systems, Inc.
Av. des Uttins 5
CH-1180 ROLLE
Switzerland
Email: jdiaconu@cisco.com
Marcelo Yannuzzi
Cisco Systems, Inc.
Av. des Uttins 5
CH-1180 ROLLE
Switzerland
Email: mayannuz@cisco.com
Diaconu, et al. Expires 5 February 2027 [Page 36]
Internet-Draft AuthZ Sharing for Agents August 2026
Herve Muyal
Cisco Systems, Inc.
Av. des Uttins 5
CH-1180 ROLLE
Switzerland
Email: hmuyal@cisco.com
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249, 3rd Floor
40549 DUESSELDORF
Germany
Email: fbrockne@cisco.com
Nik Kale
Cisco Systems, Inc.
170 W Tasman Dr
SAN JOSE, CA, 95134
United States of America
Email: nikkal@cisco.com
Ankit Agarwal
Skyfire, Inc.
Kentfield, CA,
United States of America
Email: ankit@skyfire.xyz
Jeffrey Hickman
Ory Corp, Inc.
15169 N Scottsdale Rd Suite 205
Scottsdale, AZ, 85254
United States of America
Email: jeff.hickman@ory.com
Amritha Lal
Amazon Web Services
Seattle, WA,
United States of America
Email: amrithak@amazon.com
Diaconu, et al. Expires 5 February 2027 [Page 37]