[Feat]: In-band confirmation

### Is your feature request related to a problem? Please describe.

AFAIK, there are (at least) 4 ways to implement user confirmations for agents:
1. Agent uses a out-of-band channel it already has with the user. Example: a bank agent may already have a preliminary relationship with a user, thru their smartphone; and thus can prompt a user for confirmation thru this existing secure channel.
2. Agent uses an enterprise [enforcement endpoint](https://github.com/google/A2A/issues/387), which has a mechanism to prompt the user - again, out of band.
3. Agent uses an "in-band" confirmation mechanism. The agent essentially indicates to the caller (which itself may be an agent) that it requires user confirmation. The confirmation request gets propagated back to the agent calls stack until it reaches the user. a2a specs support a "input-required" state for this, but afaik, there's no guarantee the legitimate user confirmed: the confirmation may be subject to prompt injection or a middle agent box may reply instead.
4. Hybrid in-band. Same as (3), but the reply from the user is not in-band. Instead, the agent's confirmation request is a link that the user clicks. So the user confirmation itself is out-of-band, similar to (1). This may be achievable using [OAuth RFC 9470](https://datatracker.ietf.org/doc/rfc9470/) and [MCP's userInteraction](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/475).

### Describe the solution you'd like

For (3) (and maybe (4)), we may require stronger security guarantees (confidentiality, integrity, non-replay) that the user indeed confirmed.
Some directions:

* Encrypted tunnel (There are known ways to do this. e.g., Sign+Mac, IEEE, Noise, etc). The user's client establishes a secure channel with the agent that requires confirmation.
* Hybrid encryption (aka Sign + encrypt) with a unique ID in the message (to protect against replay attacks). There are known ways to do this. (If confidentiality is not a problem, signing is enough).
* Maybe others?

The user requires some pub key to make the above possible. This could simply be an ephemeral key created for a given session / task (details TBD) by the client software. With the above mechanism in place, the agent can have proof that the user who initiated the session has confirmed the message: when receiving a confirmation request, the user would be prompted to manually confirm (What the exact UI looks like is out of scope of a2a, iiuc).

If a middle agent's box is compromised zo, there is still a risk that it would allow an attacker to provide an arbitrary pub key under their control and forge the confirmation message. There are (at least) 2 options here:

* We never give an oauth token (with the relevant scopes) to middle boxes / agents for actions that require user confirmation. Then the token can be sent thru the the encrypted channel. Today, I don't think oauth tokens are granular enough to separate scopes that would require user confirmation vs. those that do not. Another limitation is that the confirmation needs to be a predefined decision (can't be dynamically decided at runtime based on other security signals) - that may be fine for many use cases.
* We bind the user identity to the user's pub key. For example: if the agent requiring user confirmation is a bank, this pub key should be bound to the user's account / identity with the bank. Oauth has support for something like this (called [DPOP](https://oauth.net/2/dpop/)). At a high-level, it adds a user pub key inside the oauth token. The bank would only accept pub key that matches the identity of the user who needs to confirm (which it finds in the oath token used for authn). I'm not aware of oauth providers supporting this feature atm.

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct