OID4VC in Agent2Agent protocol: In-Task Authorization

Abstract

When today's AI agents interact, they have no standard way to prove who they are, what they are qualified to do, or on whose authority they act.

The Agent2Agent (A2A) protocol addresses agent communication by defining a common language for structured, interoperable agent-to-agent interaction. However, traditional security mechanisms (OAuth 2.0, API keys) leave a gap when it comes to decentralized trust, meaning agents cannot easily prove qualifications, certifications, or regulatory status issued by independent third parties.

Self-Sovereign Identity (SSI) and Verifiable Credentials (VCs) offer a compelling answer to this gap. VCs are cryptographically signed claims that can be verified without contacting the issuer, providing a portable trust layer well-suited for autonomous agent interactions. On the protocol side, OpenID for Verifiable Presentations (OID4VP) provides a great option to build VC-based this trust layer on top of the familiar OAuth 2.0 foundation.

This article presents the OID4VP In-Task Authorization Extension for the A2A protocol. The extension enables Server Agents to dynamically request Verifiable Presentations from clients during task execution, providing Just-In-Time (JIT) authorization without breaking the protocol flow. We describe the motivation behind this work, explain how A2A and OID4VP complement each other, and provide references to open-source implementations (including integration with Heka Identity Platform and LFDT Hiero project) to help explore the approach in practice.

What is Agent2Agent (A2A) protocol?

The Agent2Agent (A2A) Protocol is an open standard designed to enable structured, interoperable communication between independent, potentially opaque AI agent systems. At its core, A2A defines a common language and interaction model for ecosystems where agents might be built using different frameworks, languages, or by different vendors.

Originally developed by Google and now donated to the Linux Foundation, A2A is collaboratively driven by an open community with contributions and alignment from major industry players. The A2A Technical Steering Committee (TSC), responsible for technical oversight of the protocol specification and official SDKs, includes representatives from Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, and IBM.

Technical Concept

In contrast to wrapping agents as "tools," A2A treats each entity as an opaque agent. Agents collaborate effectively without exposing their internal logic, memory, or proprietary tools. Instead, interactions rely on declared capabilities and exchanged context. This enables agents to operate as true peer collaborators rather than siloed components or tool proxies (as illustrated below).

The A2A design uses a set of core concepts that define agent interaction:

• Core actors: User ↔ A2A Client (Client Agent) ↔ A2A Server (Remote Agent)
• Agent Card: A JSON metadata document describing an agent's identity, capabilities, endpoint, supported features (like streaming or push notifications), and authentication requirements.
• Task: The fundamental, stateful unit of work in A2A. Tasks progress through defined states and can be long-running.
• Message: A single communication turn between agents, composed of one or more Parts, which comprise of content containers holding text, files, or structured data.
• Artifact: A concrete output produced by an agent within a task (e.g., documents, images, structured results).
• Authentication and Authorization: Agents declare security requirements via the Agent Card and rely on standard web authentication mechanisms (e.g., OAuth tokens).
• Extensibility: Support for custom functionality via protocol extensions declared in Agent Card metadata.

A2A addresses key challenges in multi-agent ecosystems. The lack of standard agent discovery mechanisms, limited interoperability, and scalability constraints are common problems for decentralized systems. These issues become more relevant for agent ecosystems at scale. A2A's core consideration is that agents are powerful individually but fragmented collectively, and should be able to collaborate as peers to reach in order to increase effectiveness.

Core Use Cases

While A2A is designed for standard multi-agent ecosystems, several real-life use cases stand out:

• Enterprise agent collaboration: Internal agents (HR, finance, ops) interact securely across organizational boundaries.
• Cross-organization workflows: Agents from different companies coordinate (e.g., supply chain, identity verification, compliance checks).
• Tool-as-agent ecosystems: APIs and services are wrapped as agents, making them discoverable and composable via A2A.
• Autonomous service marketplaces: Agents advertise capabilities and are dynamically invoked by others based on specific needs.

Adoption Perspectives

A2A positions agent communication as a standard, interoperable layer, similar to how web protocols enable services to interoperate across the internet. While multiple agent-to-agent communication standards are expected to develop, A2A stands in a strong position for widespread adoption in the near future.

The key factors include:

• Broad ecosystem engagement and openness: Published as an open standard with community governance, aligning with industry trends toward collaborative standards rather than vendor‑locked solutions.
• Alignment with existing web standards: Built on established technologies (HTTP, JSON‑RPC, SSE), A2A integrates easily into existing enterprise infrastructure, reducing the barrier to adoption.
• Enterprise readiness: Incorporates security authentication/authorization hooks, long‑running operations, and asynchronous communication — features expected in enterprise workflow protocols.
• Complementary ecosystem positioning: Positioned alongside Model Context Protocol (MCP) and agent development frameworks (e.g., ADK), enabling rich stacks where agents can both reason with models and collaborate with each other.
• Extensibility as a design principle: Highly adaptable to specific needs via extensions.

In the long term, A2A has the potential to become a foundational protocol for multi-agent systems, enabling a shift from isolated AI applications to fully networked agent ecosystems.

About Verifiable Credentials (VC) and OpenID for Verifiable Credentials (OID4VC)

Self-Sovereign Identity (SSI) represents a shift from platform-controlled identity to entity-controlled identity, where users, organizations, or agents manage their own credentials without relying on centralized intermediaries. A core concept of SSI is Verifiable Credentials (VCs), which are cryptographically signed digital credentials that allow an issuer to make claims about a subject, which can be independently verified without contacting the issuer directly.

The VC-based trust model introduces a new paradigm:

• Trust is decentralized and anchored on cryptographic proofs rather than platform-based
• Verification is decoupled from issuance
• Data sharing is minimal and consent-driven

VCs provide the foundation for answering key trust questions for agent ecosystems where autonomous decision-making, cross-domain interactions, and limited human oversight are the norm. 

• Portable, verifiable identity — agents can present cryptographically signed credentials across ecosystems without relying on a shared identity provider.
• Delegated authorization encoded as credentials — permissions and roles are issued as VCs, decoupling authorization from any single platform.
• Trust decisions based on governance / policy — verifiers evaluate credentials against trust frameworks (issuer, schema, revocation status) that can be integrated with various governance mechanisms.
• Qualifications and compliance proofs — agents can prove certifications, regulatory status, or other qualifications issued by independent third parties.

In effect, VCs form a portable trust layer that complements communication protocols like A2A, enabling a secure and trusted interaction between agents.

While VCs define the trust model, a standardized protocol is needed to exchange them in practice. OpenID for Verifiable Credentials (OID4VC), a family of specifications developed by the OpenID Foundation, does just that, by operationalizing the VC trust layer at the protocol level. OID4VC defines interoperable flows for both VC issuance and presentation, represented by two separate protocols:

• OpenID for Verifiable Credentials Issuance (OID4VCI)
• OpenID for Verifiable Presentations (OID4VP)

A key design principle of OID4VC is its' foundation on existing web identity standards, making SSI compatible with OAuth 2.0 / OpenID Connect ecosystems rather than introducing an entirely separate stack. This alignment has driven widespread adoption, including large-scale deployments such as the European Digital Identity Wallet (EUDI) and mobile driver's license (mDL) ecosystems. These recent adoptions are confirming OID4VC's role as a crucial part of emerging decentralized identity infrastructure.

OpenID for Verifiable Presentations (OID4VP) and its adoption advantages

OpenID for Verifiable Presentations (OID4VP) defines how a holder proves possession of one or more VCs to a verifier in a secure, standardized, and privacy-preserving way.

At a high level, the interaction follows a structured request-response model:

1. A Verifier sends a presentation request (required claims, constraints, acceptable issuers).
2. The Holder selects matching credentials.
3. A Verifiable Presentation (VP) is generated and returned to the Verifier.
4. The Verifier verifies the presentation (signatures / data integrity, required claims and constraints).
5. Based on the verification result, the Verifier makes a trust decision, either granting or denying access to the requested resource or action.

The following diagram illustrates the high-level OID4VP cross-device flow:

Building on OAuth 2.0, OID4VP reuses familiar concepts like authorization requests, client identifiers, redirect-based flows, and also inherits established security models. OID4VP also supports flexible interaction patterns, from browser-based flows to mobile wallet integration and cross-device scenarios (QR-based flows, Digital Credentials API). This makes it straightforward for organizations to extend existing identity infrastructure rather than rebuild it.

A2A Protocol Extension: OID4VP In-Task Authorization

Taking into account synergy between SSI concepts and emerging multi-agent infrastructure, a DSR team has developed an A2A extension that provides an option to use OID4VP protocol for In-Task Authorization.

The integration of OID4VP flow allows A2A Server Agents to perform additional authorization by requesting Verifiable Presentations (VPs) from the A2A Client. This mechanism enables Just-In-Time (JIT) authorization, where the server can dynamically request information from specific VCs during a task execution without breaking the protocol flow.

Motivation

The motivation behind the extension is based on common limitations of the traditional security model leveraged by the core A2A spec. A2A relies on standard web security schemes (OAuth2, APIKey, mTLS). While these effectively handle service identity and access control, they have limitations regarding decentralized trust:

• Permissions vs. Qualifications: OAuth 2.0 Access Tokens typically assert that an agent is allowed to access a resource (e.g., scope: "tasks.read"). They do not easily prove inherent qualifications, certifications, or regulatory status of the agent itself (e.g., "This agent is a Licensed Financial Advisor").
• Centralization Bottlenecks: To validate an agent's qualifications via standard OAuth, the Authorization Server must be the single source of truth for all claims. This limits the ability of agents to present proofs issued by third parties (e.g., government bodies) without complex federation.
• Static Trust: Authorization often happens at the connection level. There is no standard flow for "step-up" verification where a specific task requires the agent to present a specific credential dynamically.
• Interoperability with Verifiable Credentials the users may already have: There is no way for an Agent to leverage VCs that the user may already have in their wallet (such as Google Wallet or Apple Wallet) as part of general adoption of VCs and decentralized identity and corresponding regulations (examples include eIDAS2/EUDI in EU and mDL/mdoc in US).

OID4VP is a natural fit for the A2A extensibility model, by layering VC-based trust on top of A2A's existing communication flow without requiring changes to the core protocol. As VC-based trust frameworks become more widely adopted, this integration has the potential to become a common pattern for A2A deployments.

Benefits for A2A Use Cases

The extension addresses each of the limitations above and brings additional capabilities to A2A interactions:

• Decentralization & Vendor Neutrality: By using OID4VP, trust is decoupled from centralized Authorization Servers. An "Airline Agent" can verify a "Corporate Booking Agent" based on a credential issued by a totally different entity (e.g., a Travel Association), without pre-registering API keys or federating auth servers. Agents cryptographically prove capabilities using credentials issued by third-party Trust Anchors (e.g., Governments, Regulatory Bodies) without the Verifier needing to integrate with those issuers directly.
• Granular, Context-Aware Security (JIT): Instead of over-privileged sessions with broad scopes granted at connection time, the JIT flow allows for the Principle of Least Privilege. A session can start with low privileges, and the Server can request high-assurance credentials only when a specific sensitive task is requested (e.g., "Transfer Funds").
• Bridging AI Agents with Human Wallets: Many high-value credentials (e.g., National IDs, Corporate Signing Keys) reside in human-controlled Digital Wallets, not on servers. The JIT flow enables Human-in-the-Loop authentication: a Client Agent can receive a challenge, forward it to a user's mobile wallet for approval/signing, and return the result, effectively acting as a bridge to a human's legal identity.
• Interoperability with modern Identity approaches: VCs can be presented from various wallets (such as Google Wallet, Apple Wallet, etc.), enabling conformance with modern digital identity patterns and regulations (such as eIDAS2 / EUDI).
• Non-Repudiation & Auditability: Unlike mutable API Key usage logs, a Verifiable Presentation is cryptographically signed by the Holder and bound to a specific request nonce. This provides a non-repudiationable audit trail proving exactly which credential was presented for which task, essential for liability in autonomous agent networks.

How It Works

The extension integrates into A2A through its standard extensibility mechanisms. At the protocol level, the key elements are:

• AgentCard declaration: An agent that supports OID4VP In-Task Authorization declares it in the extensionssection of its AgentCapabilities, including supported OID4VP versions. This makes the capability machine-discoverable.
• Transition to TASK_STATE_AUTH_REQUIRED: When a Server Agent determines that additional authorization is needed during task execution, it transitions the task to this state and includes an authorizationRequestobject in the message metadata.
• Authorization Request structure: The authorizationRequest object follows Section 5 of the OID4VP specification and contains the parameters needed for the Client to initiate the OID4VP flow (e.g., client_id, request_uri or request object).
• Wallet invocation patterns: The spec considers two integration models, one where the end-user holds VCs in a standalone wallet (e.g., Google Wallet, Apple Wallet) and the A2A Client invokes it, and another where the A2A Client Agent directly controls its own wallet module (e.g., via MCP).

The diagram below shows a non-normative example of an OID4VP A2A in-task authorization flow:

Reference Implementations

At the moment, there are two open-source reference implementations that leverage the extension.

• Sample in extension repo — a minimal setup that validates the extension flow end-to-end, where a CLI Client serves as both A2A Client and OID4VP Wallet authorizing against an OID4VP request from A2A Server (acting as OID4VP Verifier)
• Demo of A2A OID4VP In-Task Authorization with Heka Identity Platform (LFDT Hiero project) — demonstrates cross-device wallet invocation in a realistic identity platform scenario, where A2A Client invokes a Mobile VC Wallet (Heka Wallet app) to perform authentication requested by A2A Server

Both implementations aim to provide practical examples of how to implement and use the extension. Feel free to try them out, explore the provided capabilities, and see how they can be applied to the scenarios you might have in mind.

What's Next?

With multi-agent ecosystems emerging rapidly and VC-based trust frameworks gaining adoption, it's important to maintain a robust extension specification and provide implementors with practical guidance and reference implementations.

At DSR, we're committed to long-term stewardship of the OID4VP In-Task Authorization extension and to driving its recognition in the A2A community.

The A2A Extension Governance defines a specific process for recognition and adoption of extensions. Extensions supported by the community and approved by the A2A TSC can ultimately be promoted to the core protocol specification. We're committed to following this process, with the next steps being:

1. Becoming an "experimental" extension hosted in a repository under the A2A Project
2. Gathering broader community feedback and maturing the extension specification
3. Graduating from "experimental" status to an official A2A Extension by meeting maturity requirements and passing the A2A TSC vote

In this context, open community discussion for the extension and its use cases is crucial. If you have any feedback or questions regarding the concept, feel free to contact our team at contact@dsr-corporation.com