[Feat]: Data handling declarations for Agent Cards

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

### The gap

A2A is being designed with enterprise adoption in mind, but Agent Cards currently have no way to express **what an agent does with data** — retention, processing location, model training, sub-processing practices. This is the kind of gap that costs very little to address now,
but becomes a major blocker later when regulated industries (healthcare, finance, any EU deployment) try to adopt the protocol.

This pattern is well-documented: features ship without data handling metadata, then spend months retrofitting for GDPR/CCPA before they can launch in regulated markets. A2A has the opportunity to get ahead of this by providing the vocabulary from the start — especially since
the [extensions](https://a2a-protocol.org/latest/topics/extensions/) documentation already envisions a data-only extension for "structured data about an agent's GDPR compliance."

This isn't a nice-to-have — organisations deploying A2A agents will face legal requirements in key markets that demand this information. GDPR Article 25 mandates data protection **by design**, not as a retrofit. Article 28 requires the controller to authorise sub-processing and
holds the initial processor fully liable for every sub-processor in the chain. When Agent A delegates to B who sub-delegates to C, each hop processes data under different policies — and whichever party bears controller obligations currently has no protocol-level way to
evaluate any of it before sending data:

- **Where** is data processed? (EU? US? Unknown?)
- **How long** is it retained?
- **Is it used** for model training?
- **What happens** on delegation — do data handling commitments hold across the chain, or break at the first hop?

**The first step is vocabulary.** Think of it like accounting standards (IFRS, GAAP): the standard provides a structured format for self-reporting; auditors verify; regulators enforce. A2A can provide the shared language that makes enforcement possible — without needing to
solve enforcement itself.

### Describe the solution you'd like

### A possible direction

One approach: a data-only extension adding self-declared data handling properties to Agent Cards. For example, imagine something like:

```json
"extensions": [{
"uri": "urn:a2a:ext:data-handling/v1",
"params": {
"processing_locations": ["DE", "FR"],
"model_training": false,
"retention": "request_only",
"policy_url": "https://example.com/data-policy"
}
}]
```

Other properties worth discussing: sub-processing constraints (what happens on delegation), third-party sharing, regulatory frameworks the operator claims to operate under.

Initially these would be self-declared — the extension provides the information layer that automated filtering, verification mechanisms, and enforcement policies can build on.

Some of these properties are being explored in ongoing work (e.g., https://github.com/StevenJohnson998/agent-data-handling-policy, Apache 2.0), though the community may prefer entirely different approaches.

Questions for discussion

1. Is this the right scope? Standalone data-only extension, part of a broader governance extension (#1603), or candidate for core Agent Card fields?
2. Which properties matter most? If your customers operate in regulated markets, what would they need to know about an agent's data handling before they could adopt it?

Happy to draft a PR based on community feedback.

### Describe alternatives you've considered

### Relationship to existing work

Several proposals address different facets of agent trust — data handling is the missing piece:

- **#1497** (Identity Verification) — *who is the agent?*
- **#1501** (Trust Scoring, closed) → **#1604** (behavioral trust scoring) — *how has the agent behaved?*
- **#1575** (Agent Passport) — identity + delegation enforcement
- **#1603** (IACS compliance extensions) — broader governance framework covering approval policies, forbidden actions, task-level compliance
- **This gap** — *what does the agent do with my data?*

This could potentially integrate as a focused module within the broader governance effort (#1603), or stand alone as a data-only extension. Properties could align with established vocabularies: ISO 3166-1 for jurisdictions, W3C Data Privacy Vocabulary for data categories and
processing purposes.

### Additional context

_No response_

### Code of Conduct

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