[Web-bot-auth] Re: Implementation report: per-agent hosted directories (httpsig-protocol-00)

[Thibault Meunier <[e-mail]>]

Hi James,

Thanks for the message. Reformulating to ensure I understand your question

Your setup is each agent manages their own keys published under a dedicated directory managed by the user. When something happens and the user wants to disable the agents, they remove its key from the directory.

What you'd like is some more authoritative wording so that verifier SHOULD respect Cache-Control header. Is this correct?

I think it's generally a good idea. I'm more concerned with your setup. It seems that the simpler solution would be to prevent the agent from making request in the first place. Should there be an HTTP message signature on the message or not, the request is made anyway. Especially since each agent has their own directory.

Thibault

On Sunday, October 4th, 2026 at 14:11, James Huang <[e-mail]> wrote:

> Hi all,
>
> I run a small open-source service, Auth Your Agent (https://github.com/kjames2001/authyouragent, MIT), that lets a person's AI agent act for them on websites. We implement draft-ietf-webbotauth-httpsig-protocol-00, and I have one question about caching.
>
> Our setup: the agent browses through a sandboxed browser on the user's own machine. That browser makes its own Ed25519 key and signs its requests, so the private key stays with the user. We host the public key, one directory per agent, at
>
> Https://<label>.agents.authyouragent.com/.well-known/http-message-signatures-directory
>
> with the Appendix B.1 proof. Each agent is its own Signature-Agent, so if one gets blocked the others are unaffected. Cloudflare's web-bot-auth library verifies our signatures against these directories in production; I re-ran that check today. Happy to be listed in Appendix F if that helps.
>
> The question. With us, the user decides when an agent loses access. When they withdraw it, we serve that agent's directory with no keys, which 6.10 treats as evidence, and 5.5.2 says the key stops verifying once the verifier's cached copy expires. We used to send max-age=3600. Today we cut it to 300, since an hour is a long time when the agent has just bought something the user disputes.
>
> That only helps if verifiers keep to it. C.4 says they "should respect Cache-Control", but it is lowercase guidance in an appendix, and nothing stops a verifier from setting its own floor of an hour or a day. Since removing a key is the only way to deactivate one, would the group consider moving that into 5.5.2 as a normative SHOULD? Or is a verifier-side floor meant to be allowed? (Who the agent acts for, and what the user approved, we handle with OpenID Connect: the agent goes in the `act` claim, and CIBA covers each approval. Nothing is needed here for that.)
>
> Thanks,
>
> James