docs(spec): Added normative content to specification.md that lived in topics

docs/specification.md

@@ -310,6 +310,17 @@ Agent Cards themselves might contain information that is considered sensitive.
 - If an Agent Card contains sensitive information, the endpoint serving the card **MUST** be protected by appropriate access controls (e.g., mTLS, network restrictions, authentication required to fetch the card).
 - It is generally **NOT RECOMMENDED** to include plaintext secrets (like static API keys) directly in an Agent Card. Prefer authentication schemes where clients obtain dynamic credentials out-of-band.
 
+#### 5.4.1. Conditional Disclosure (Selective Cards)
+
+Agents **MAY** vary the content of the Agent Card based on the authenticated caller identity. When doing so:
+
+- Any reduced (public) view **MUST NOT** misrepresent supported authentication requirements or transports.
+- Omitted skills or extensions **MUST NOT** be implicitly required for successful invocation of the public interface.
+- Sensitive fields (e.g., internal-only skills, extension parameters) **MUST** only appear for authorized identities.
+- Clients **MUST NOT** assume that a minimal card implies absence of additional capabilities unless the card sets `supportsAuthenticatedExtendedCard: false`.
+
+If conditional disclosure is used, the agent **SHOULD** set `supportsAuthenticatedExtendedCard: true` to signal that an authenticated, extended version exists.
+
 ### 5.5. `AgentCard` Object Structure
 
 {{ render_spec_tabs('AgentCard') }}
@@ -1922,3 +1933,133 @@ Implementations **SHOULD** validate compliance through:
 - **Error handling**: Verify proper handling of all defined error conditions.
 - **Data format validation**: Ensure JSON schemas match the TypeScript type definitions in [`types/src/types.ts`](https://github.com/a2aproject/A2A/blob/main/types/src/types.ts).
 - **Multi-transport consistency**: For multi-transport agents, verify functional equivalence across all supported transports.
+
+## 12. Extensions (Normative)
+
+Normative rules for extensions. Background and examples: [Extensions topic](./topics/extensions.md).
+
+### 12.1. Extension Taxonomy (Informative)
+Categories (non-normative labels): data-only, profile, method.
+
+### 12.2. Declaration
+Agents **MUST** declare supported extensions in `AgentCapabilities.extensions` via `AgentExtension` objects. Each extension **MUST** have a globally unique URI.
+
+### 12.3. Prohibited Changes
+Extensions **MUST NOT** add/remove required fields, remove optional fields, add enum values, or redefine semantics of existing core fields. Custom attributes **MUST** go in `metadata` or `AgentExtension.params`.
+
+### 12.4. Required Extensions
+If `required == true`, the server **MUST** reject requests that do not activate the extension. Data-only extensions **SHOULD NOT** be required.
+
+### 12.5. Activation Handshake
+Clients request activation with header `X-A2A-Extensions: <uri>[, <uri>...]`.
+Rules:
+1. Unknown URIs **MUST** be ignored.
+2. Server **SHOULD** echo activated set in response header `X-A2A-Extensions`.
+3. Missing activation of a required extension **MUST** cause rejection.
+4. Activation is per-request unless an extension spec states otherwise.
+
+### 12.6. Dependencies
+Extensions **MAY** declare dependencies; clients **MUST** activate required dependencies or be rejected.
+
+### 12.7. Versioning
+Breaking changes **MUST** use a new URI; servers **MUST NOT** silently substitute versions.
+
+### 12.8. Security
+Extension methods/data **MUST** follow core authN/Z; inputs **MUST** be validated.
+
+### 12.9. Errors
+Extension validation failures **SHOULD** use standard error format with extension metadata in `error.data`.
+
+### 12.10. Publication
+Implementations **SHOULD** host specification at the extension URI (or permanent redirect) for discoverability.
+
+## 13. Task Refinement & Follow-Ups
+
+Normative rules; narrative examples: [Life of a Task](./topics/life-of-a-task.md).
+
+### 13.1. Immutable Tasks
+Terminal tasks **MUST NOT** be restarted. Refinements **MUST** create new tasks.
+
+### 13.2. Context Reuse
+Clients **SHOULD** reuse `contextId` for follow-ups to preserve context.
+
+### 13.3. Ambiguity Handling
+If prior artifact/task reference is ambiguous the server **SHOULD** return `TASK_STATE_INPUT_REQUIRED` requesting clarification.
+
+### 13.4. Artifact Lineage
+Refined artifacts **SHOULD** retain human-readable `name` while using a new immutable `artifactId`.
+
+### 13.5. Parallelism
+Multiple concurrent tasks under a single `contextId` are allowed; each task lifecycle is independent.
+
+## 14. Streaming Semantics & Reconnection
+
+Additional norms; background: [Streaming & Asynchronous Operations](./topics/streaming-and-async.md).
+
+### 14.1. Ordering
+Servers **MUST** emit: initial `Task` → zero/more updates → single `final` status update → close.
+
+### 14.2. Final Event
+`final == true` **MUST** appear exactly once per streaming phase and only when task is interrupted or terminal.
+
+### 14.3. Resubscribe
+On reconnection server **MAY** send current snapshot then only new deltas; clients **MUST** handle idempotent replays.
+
+### 14.4. Artifact Chunking
+Ordering of appended chunks **MUST** reflect assembly order; `last_chunk == true` signals completion of that artifact stream.
+
+### 14.5. Premature Close
+Clients **SHOULD** attempt resubscribe if stream ends without a `final` event.
+
+## 15. Observability & Operations
+
+Complementary guidance: [Enterprise-Ready Features](./topics/enterprise-ready.md).
+
+### 15.1. Tracing
+Agents & clients **SHOULD** propagate W3C Trace Context headers.
+
+### 15.2. Logging
+Servers **SHOULD** log identifiers (`taskId`, `contextId`, request ID) and errors; avoid logging sensitive content.
+
+### 15.3. Metrics
+Expose counts, latency, error rates, streaming connection metrics.
+
+### 15.4. Auditing
+Sensitive operations **MUST** be auditable with immutable identifiers and principal.
+
+### 15.5. Correlation IDs
+`X-Correlation-Id` (or similar) **MAY** be echoed.
+
+## 16. Push Notification Security (Expanded)
+
+Details beyond Section 10.2; background: [Streaming & Asynchronous Operations](./topics/streaming-and-async.md#security-considerations-for-push-notifications).
+
+### 16.1. URL Validation
+Servers **MUST** mitigate SSRF via allowlists, network checks, or challenge verification before first use.
+
+### 16.2. Challenge
+Unverified webhook URLs **MUST NOT** receive notifications.
+
+### 16.3. Authentication
+If `authentication.schemes` provided, server **MUST** apply one (Bearer/API Key/mTLS/HMAC) or reject config.
+
+### 16.4. Token Header
+If `token` provided server **SHOULD** echo in `X-A2A-Notification-Token`; receiver **MUST** validate.
+
+### 16.5. Replay Protection
+Signed timestamp + unique ID **SHOULD** be present; receivers **SHOULD** reject stale/duplicate.
+
+### 16.6. Key Rotation
+JWT/JWS public keys **SHOULD** be published via JWKS with overlap during rotation.
+
+### 16.7. Payload Size
+Minimal payload (taskId + state) **SHOULD** prompt client fetch for full Task if large artifacts expected.
+
+### 16.8. Retries
+Transient failures (5xx / network) **SHOULD** be retried with backoff; persistent 4xx (except 429) **SHOULD NOT**.
+
+### 16.9. Rate Limiting
+Per-destination limits **SHOULD** be enforced to prevent abuse/amplification.
+
+---
+Cross-reference quick map: Extensions (§12), Refinements (§13), Streaming specifics (§14), Observability (§15), Push notification security (§16).

docs/topics/agent-discovery.md

@@ -16,6 +16,8 @@ Client agents use the Agent Card to determine an agent's suitability, structure
 
 ## Discovery Strategies
 
+Normative discovery elements (well-known location, Agent Card structure, conditional disclosure) are defined in [Spec §5](/specification/#5-agent-discovery-the-agent-card).
+
 The following sections detail common strategies used by client agents to discover remote Agent Cards:
 
 ### 1. Well-Known URI

docs/topics/enterprise-ready.md

@@ -14,6 +14,8 @@ treating remote agents as standard HTTP-based enterprise applications.
 
 ## Transport Level Security (TLS)
 
+Normative transport & authentication requirements live in the specification ([Spec §§3–5, 10.2, 16](/specification/)). This topic elaborates operational guidance.
+
 Ensuring the confidentiality and integrity of data in transit is fundamental for
 any enterprise application.
 

docs/topics/extensions.md

@@ -15,6 +15,8 @@ are identified by a URI and defined by their own specification. Anyone is able t
 The flexibility of extensions allows for customizing A2A without fragmenting
 the core standard, fostering innovation and domain-specific optimizations.
 
+Normative rules are defined in the specification (see [Spec §12 Extensions](/specification/#12-extensions-normative)).
+
 ## Scope of Extensions
 
 The exact set of possible ways to use extensions is intentionally broad,

docs/topics/life-of-a-task.md

@@ -13,6 +13,8 @@ from a client, it can respond in one of two fundamental ways:
     `input-required`, `auth-required`) or a terminal state (e.g., `completed`,
     `canceled`, `rejected`, `failed`).
 
+Normative refinement rules are captured in [Spec §13 Task Refinement & Follow-Ups](/specification/#13-task-refinement--follow-ups).
+
 ## Group Related Interactions
 
 A `contextId` is a crucial identifier that logically groups multiple `Task`

docs/topics/streaming-and-async.md

@@ -6,6 +6,8 @@ The Agent2Agent (A2A) protocol is explicitly designed to handle tasks that might
 
 For tasks that produce incremental results (like generating a long document or streaming media) or provide ongoing status updates, A2A supports real-time communication using Server-Sent Events (SSE). This approach is ideal when the client is able to maintain an active HTTP connection with the A2A Server.
 
+**Key Characteristics:** (See normative streaming & reconnection rules in [Spec §14 Streaming Semantics & Reconnection](/specification/#14-streaming-semantics--reconnection)).
+
 The following key features detail how SSE streaming is implemented and managed within the A2A protocol:
 
 - **Server Capability:** The A2A Server must indicate its support for streaming by setting `capabilities.streaming: true` in its Agent Card.
@@ -63,6 +65,10 @@ Push notifications are ideal for:
 - Clients that cannot or prefer not to maintain persistent connections, such as mobile applications or serverless functions.
 - Scenarios where clients only need to be notified of significant state changes rather than continuous updates.
 
+Normative security requirements are centralized in [Spec §16 Push Notification Security](/specification/#16-push-notification-security-expanded). This section provides explanatory background.
+
+Security is paramount for push notifications due to their asynchronous and server-initiated outbound nature. Both the A2A Server (sending the notification) and the client's webhook receiver have responsibilities.
+
 ### Protocol Specification References
 
 Refer to the Protocol Specification for detailed structures: