A2A should account for the confused deputy problem

I've originally authored an issue in MCP describing this problem [here](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/333).

I think A2A should also consider the impact of the issue and account for it. For context here's a copy of the issue over there:

>This issue is to discuss the handling of the [confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem) and determine what makes the most sense for handling this.
>
> Under the current design being discussed in https://github.com/modelcontextprotocol/modelcontextprotocol/issues/205 and the subsequent PR https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284 there's a simplified assumption being made of the MCP client. In the case of most agents, they won't be granted the full set of authorization scopes typically granted to the user's client (aka the browser). Instead, we should expect that it will be common that an agent will be granted a subset of authorization scopes specifically for performing a task.
>
> In this case, an agent (or it's child-agents) will perform separated tasks on behalf of the user and if we re-use the token that's intended for the client it will produce a confused deputy problem. To address this issue, the resource server needs to be able to identify the client and it's agents as independent entities with separated authorization scopes in order to adhere with the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
>
>---
>
>There are two ways that I can think of solving this:
>
>
> ### 1. child-agent issuance protocol
>
>In this design choice, a client/agent submits a token to the authorization server to get issued a secondary token it can grant to the child-agent to operate on its own behalf. The agent/child-agent would then present this token to the resource server.
>
> ### 2. Delegation chains using DPoP
>
> In this design choice, we instead rely on delegation chains where a client can take a subject key from a DPoP architecture (such as [DBSC](https://github.com/w3c/webappsec-dbsc)) and issue a secondary token with a subset of the authorization scopes. Then, when the agent/child-agent submits a request to the resource server (MCP server), the resource server would validate the delegation chain by verifying the token issued to the client and the token issued to the agent by the client's DPoP subject key.
>
> ---
>
> My personal preference is towards option 2 as it produces a more scalable approach by reducing the amount of requests necessary. Additionally, it allows for the ability of agents to spawn child-agents and handle authorization without coordination with the authorization server each time this occurs. However, this does rely on further changes to clients and the resource server (MCP server) in order to handle this which aren't as simple as option 1.
>
> Luckily we're pretty well heading in that direction already with [DBSC](https://github.com/w3c/webappsec-dbsc) in the client, and would just need to add a delegate functionality to make this work. On the resource server side though, we'd also need to handle the more advanced verification logic and that's what I'd like to propose as an enhancement to this spec.