Proposal: compliance extensions to Agent Cards and task semantics

Based on development such as NIST https://www.regulations.gov/document/NIST-2025-0035-0001 and IMDA https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai, please consider compliance extensions to Agent Cards and task semantics.

For Agent Card extensions:

IACS-CAP-1 (Section 6, Capability and Policy Disclosure) — defines what an Agent Assurance Card must disclose. This is the compliance superset of what A2A's Agent Card currently carries. The specific fields that A2A Agent Cards don't have but IACS requires are in Section 7.1 (the Agent Assurance Card artifact): jurisdiction_profile, forbidden_actions, memory_semantics, approval_policy, supported_iacs_versions, assurance_level, and verification_latency_profile.

For task model extensions:

IACS-TASK-1 (Section 6, Task Contracting) — defines Task Contract fields that A2A's task model doesn't currently carry. The specific missing fields are in Section 7.3: impact_tier, regulatory_risk_status, constraints, allowed_actions, forbidden_actions, approval_requirements, budget_cap, and escalation_conditions.
IACS-HAN-1 (Section 6, Handoff Sufficiency) — defines the pre-cooperation verification gate (the seven-step sequence) and the four mandatory response states (ACCEPTED, REJECTED, INPUT_REQUIRED, APPROVAL_REQUIRED). A2A has task states but doesn't require this verification sequence before acceptance.

For delegation semantics:

Section 7.2 (Delegation Credential artifact) — A2A has no equivalent. This is probably the biggest gap: a machine-readable credential binding principal, agent, purpose, scope, attenuation rules, expiry, and revocation reference.

For provenance and incident handling:

Section 7.5 (Provenance Receipt) and Section 7.6 (Incident Notice) — A2A tracks task completion but doesn't produce signed provenance records or support incident propagation across agent chains.

For reason codes:

Section 9 — A2A doesn't currently have a standardized refusal vocabulary. IACS defines 15+ hierarchical reason codes (IDENTITY_UNVERIFIED, DELEGATION_INVALID, SCOPE_EXCEEDED.*, etc.) that would make rejection responses machine-actionable.

To be honest: this is an open question from someone just entering this (git) space: I am asking whether this belongs as a core protocol extension, a namespaced extension, or a separate profile layered on top - or nothing at all. Thanks!

[IACS-1.0-v2.docx](https://github.com/user-attachments/files/25823508/IACS-1.0-v2.docx)