Is your feature request related to a problem? Please describe.
We’re implementing A2A security for cross-deployment agent calls and are using OAuth with JWT assertion (RFC 7523) as a core pattern for machine-to-machine identity propagation. In the current A2A spec, we see support for standard OAuth flows, but JWT assertion is not explicitly modeled as one of the auth flows. Could the community clarify the rationale for this omission, and whether JWT assertion is expected to be represented through existing OAuth2 metadata or considered out of scope for now? Guidance on recommended interoperability patterns for assertion-based flows would be very helpful.
Describe the solution you'd like
I’d like the A2A spec to explicitly support OAuth JWT assertion (RFC 7523) as a first-class authentication flow, or clearly document how it should be represented using existing OAuth2SecurityScheme metadata. This should include interoperable guidance for assertion grant parameters (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, assertion, optional client_assertion), expected claim/header requirements (iss, sub/prn, aud, iat, exp, jti, kid), and how agents should advertise this in Agent Card securitySchemes/securityRequirements.
Describe alternatives you've considered
We considered modeling JWT assertion implicitly under existing OAuth2 flows (for example via client credentials metadata and custom documentation), but this creates ambiguity and inconsistent implementations across agents. We also considered documenting it only in vendor-specific extensions, but that reduces interoperability and discoverability. A clear spec-level pattern for JWT assertion would provide a standard, portable approach for A2A deployments that rely on IDCS/OAuth assertion exchange.
Additional context
No response
Code of Conduct
Is your feature request related to a problem? Please describe.
We’re implementing A2A security for cross-deployment agent calls and are using OAuth with JWT assertion (RFC 7523) as a core pattern for machine-to-machine identity propagation. In the current A2A spec, we see support for standard OAuth flows, but JWT assertion is not explicitly modeled as one of the auth flows. Could the community clarify the rationale for this omission, and whether JWT assertion is expected to be represented through existing OAuth2 metadata or considered out of scope for now? Guidance on recommended interoperability patterns for assertion-based flows would be very helpful.
Describe the solution you'd like
I’d like the A2A spec to explicitly support OAuth JWT assertion (RFC 7523) as a first-class authentication flow, or clearly document how it should be represented using existing OAuth2SecurityScheme metadata. This should include interoperable guidance for assertion grant parameters (grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, assertion, optional client_assertion), expected claim/header requirements (iss, sub/prn, aud, iat, exp, jti, kid), and how agents should advertise this in Agent Card securitySchemes/securityRequirements.
Describe alternatives you've considered
We considered modeling JWT assertion implicitly under existing OAuth2 flows (for example via client credentials metadata and custom documentation), but this creates ambiguity and inconsistent implementations across agents. We also considered documenting it only in vendor-specific extensions, but that reduces interoperability and discoverability. A clear spec-level pattern for JWT assertion would provide a standard, portable approach for A2A deployments that rely on IDCS/OAuth assertion exchange.
Additional context
No response
Code of Conduct