Implementing AWS SigV4 via AgentExtension?

[LucaButBoring]

I'm looking to host A2A servers on AWS and wanted to use IAM to scope caller permissions. Previously, this wasn't possible, but with AgentExtension it sounds like this might be doable – the docs on Required Extensions even call out message signing as an explicit use case.

Unfortunately, there doesn't yet appear to be any clear language describing what extensions are allowed to do at a low level, so it's hard to see if I would be able to implement SigV4 on them right now.

I'd like to know three things about extensions in particular:

1. Where in the request lifecycle are extensions allowed to be invoked? I'd need to be able to sign an entire request and add four HTTP headers to it (docs) just prior to the request being sent.
2. What modifications can extensions make to an HTTP request? As noted in (1), I'd need to add multiple arbitrary headers to a request prior to sending it.
3. Do extensions need to be implemented in multiple languages? While I assume this is the case, there's nothing suggesting how language-specific extensions might be discovered from a URI and loaded, so it's unclear how extensions will have a way of pointing to specific sources on e.g. NPM/PyPI that should be used, or if there's going to be some language-independent way of loading extensions instead.

[mikeas1]

Hey, sorry for missing this question. I think this is a great use case for extensions.

Let me try to answer your questions:

1. Where in the request lifecycle are extensions allowed to be invoked? I'd need to be able to sign an entire request and add four HTTP headers to it (docs) just prior to the request being sent.

Technically, anywhere. The Python SDK support I plan to add will be based on lifecycle hooks, and adding a hook that alters the HTTP content of an outgoing request is a good fit. This even seems like a reasonable fit for a standard Auth handler for an httpx client, if you're using Python. Looks like there are even existing libraries for it: https://github.com/Colin-b/httpx_auth#aws-signature-v4

2. What modifications can extensions make to an HTTP request? As noted in (1), I'd need to add multiple arbitrary headers to a request prior to sending it.

Since A2A doesn't strictly dictate HTTP headers, this is allowed. The primary restriction for extensions is that they cannot modify the core types in the specification (by adding new fields or removing required fields).

3. Do extensions need to be implemented in multiple languages? While I assume this is the case, there's nothing suggesting how language-specific extensions might be discovered from a URI and loaded, so it's unclear how extensions will have a way of pointing to specific sources on e.g. NPM/PyPI that should be used, or if there's going to be some language-independent way of loading extensions instead.

At the moment, yes. Extensions are not currently setup to be loaded on-demand -- you must directly configure the set of extensions your agent or client supports. This means it's the responsibility of the developer to identify the language-specific packages that implement the extension, then configure those in whatever way the package defines.

Extensions are still very new, so I expect some of this to change, and hopefully get easier. My goal is that the SDK-level support for extensions becomes as straightforward as:

handler = DefaultRequestHandler(
  # ...
  extensions=[AWSSigV4Extension(aws_credential)],
)

[LucaButBoring]

Got it, this answers most of my questions, thanks! Regarding extension loading then (since it's lang-specific) - are there any planned ways for server agents to point clients to appropriate extension packages that client agents should be using, either through standardized error messages etc.? Requiring the client agent developer to explicitly install a client-side extension in their agent is reasonable, I'm just interested in what discovery might look like in that circumstance.

[mikeas1]

Nothing directly machine readable at this point. Since extensions are identified by a URI, my expectation is that extension developers will have that be a URL that points to documentation. They can then include links to implementation packages in their docs. Otherwise, you'd use normal search means for finding implementations of published protocols (i.e. google or npm/pypi/whatever search).