[Extension]: OID4VP for In-Task Authorization #1463
Description
Motivation
Currently, 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.
- Interop with Verifiable Credentials the users may already have: There is no way for an Agent to leverage VCs or mdocs that the user may already have in his wallet (such as Google Wallet or Apple Wallet) as part of general adoption of VCs and decentralized identity and corresponding regulations (such as eIDAS2/EUDI in EU, mDL/mdoc in US, etc.)
Extension concept
We propose to extend auth options in A2A protocol to support Verifiable Credentials (VCs) using the OID4VP (OpenID for Verifiable Presentations), specifically by supporting OID4VP as one of In-Task Authorization mechanisms.
This would also enable Just-In-Time (JIT) authorization – server can dynamically request information from specific VCs during a Task execution without breaking the protocol flow.
Please see Additional context section for benefits overview.
Proposed OID4VP In-Task Auth flow
sequenceDiagram
participant C as A2A Client
participant S as A2A Server
participant V as OID4VP Verifier
participant W as OID4VP Wallet
C -->> S: O-O-B Communication
S ->> C: Additional authorization needed<br/>Task status: TASK_STATE_AUTH_REQUIRED<br/>Message response with authorizationRequest object
C ->> W: OID4VP Wallet invocation
W ->> V: Requests Authorization Request
V ->> W: Authorization Request
W ->> W: Requests End-User consent (if applicable)
W ->> W: Creates a Verifiable Presentation (VP) that matches Authorization Request
W ->> V: VP
V ->> V: Verifies VP
V ->> S: Approves task execution (out-of-band)
S ->> C: Additional authorization passed<br/>Task status: TASK_STATE_WORKING<br/>(received via Task subscription or status polling)
Such integration of OID4VP can be supported as an extension and looks like a good "default" option for supporting VC-based auth and trust frameworks, while also having a potential to become one of the "common workflows" for A2A in future.
Use cases involving VCs and decentralized trust are expected to become more relevant in near future (eIDAS2/EUDI in EU, mDL/mdoc in US) and OID4VP standard is being widely adopted.
We published a draft version of OID4VP In-Task Authorization extension.
Any feedback is much appreciated!
Additional context
Benefits for A2A use cases
Decentralization & Vendor Neutrality
Reliance on centralized Authorization Servers creates a single point of failure and a trust bottleneck.
By using OID4VP and DIDs, trust is decoupled. 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. OID4VP allows agents to 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)
Standard OAuth often results in over-privileged sessions where an agent is granted broad scopes (e.g., write:all) at connection time.
The JIT (Just-in-Time) 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. This effectively allows an AI agent to act as a bridge to a human's legal identity.
Interoperability with modern Identity approaches and integration with existing Wallets
The VCs can be presented from various wallets (such as Google Wallet, Apple Wallet, etc.) which improves interoperability and enables conformance with modern digital identity patterns and regulations (such as eIDAS2 / EUDI).
Non-Repudiation & Auditability
API Key usage logs are mutable and difficult to prove in a dispute.
A Verifiable Presentation is cryptographically signed by the Holder and bound to a specific request nonce. This provides a non-repudiatable audit trail proving exactly which credential was presented for which task, essential for liability in autonomous agent networks.
Code of Conduct
- I agree to follow this project's Code of Conduct