Question

Why is supports_authenticated_extended_card a top-level field on AgentCard instead of being part of AgentCapabilities?

Current State

Location: specification/grpc/a2a.proto

message AgentCard {
  // ...
  // Whether the agent supports providing an extended agent card when authenticated.
  optional bool supports_authenticated_extended_card = 13;
  // ...
}

message AgentCapabilities {
  // Indicates if the agent supports streaming responses.
  optional bool streaming = 1;
  // Indicates if the agent supports sending push notifications for asynchronous task updates.
  optional bool push_notifications = 2;
  // A list of protocol extensions supported by the agent.
  repeated AgentExtension extensions = 3;
  // Indicates if the agent provides a history of state transitions for a task.
  optional bool state_transition_history = 4;
}

Discussion

The supports_authenticated_extended_card field appears to be a capability (an optional feature that the agent may or may not support), similar to:

• streaming
• push_notifications
• state_transition_history

However, it's placed at the top level of AgentCard rather than within the capabilities field.

Questions

1. Is there a semantic reason for this distinction? Does the extended agent card concept differ fundamentally from other capabilities?

2. Should this be moved to AgentCapabilities? This would provide a consistent location for all optional features.

3. Was this a deliberate design choice? If so, understanding the rationale would help with future capability additions.

4. Impact on consistency: Having capabilities split between two locations may confuse implementers about where to look for feature support.

Potential Benefits of Moving to Capabilities

• Consistency: All optional features in one place
• Discoverability: Clearer for clients looking for what an agent supports
• Logical grouping: Capabilities are already the designated place for optional features
• Future-proofing: Establishes a clear pattern for adding new optional features

Considerations

• This would be a breaking change requiring migration (though v1.0 is the right time for such changes)
• Existing implementations may rely on the current location
• May need to maintain backward compatibility or provide clear migration guidance