[Web-bot-auth] Re: What does draft-meunier-webbotauth-httpsig-protocol do?

[Kaveh Ranjbar <[e-mail]>]

Hi EKR, all,

Two functions, continuity and tie-back to a real-world identity, is the
right decomposition, and I agree the WebPKI is a reasonable anchor for the
domain-bound case. I want to push on one point, because I think the DNSSEC
option is being closed for a reason that does not apply to what we are
building here.

The "dire deployment" objection is a statement about two population-level
metrics: how many zones are signed, and how many third-party resolvers
validate. The validation figure people cite, about a third of users,
measures the resolvers sitting in front of ordinary browsers. That is the
wrong denominator for this design. Here the verifier is not a browser and
not a user's ISP resolver. It is the server receiving the bot's request,
and it can run its own validating resolver on localhost. It then either
gets a complete signature chain to the root or it refuses,
deterministically, whatever the rest of the internet deploys.

This matters because the historical failure of DANE for the web was a
browser and last-mile problem: browsers would not validate, and the path
from stub to recursive was not authenticated. That failure mode does not
exist for a server-side verifier doing its own validation. Importing
"DNSSEC is not deployed enough for browsers" into a server-to-server
context is a category error, and I think it is doing a lot of the work
behind "WebPKI is the clear winner."

What has to hold universally for this to work is not global adoption, it is
the chain from the root to the operator's TLD, and that part is not best
effort. The root is signed under a bound, witnessed key-ceremony process.
Every gTLD is signed, new-gTLD operators are contractually required to sign
their zone and to accept DS records from child domains under Specification
6 of the ICANN base registry agreement, and registrars are required to
relay that material under the 2013 RAA. So for any name under a signed TLD,
which is every gTLD plus the major signed ccTLDs, the only two parties who
have to do anything are the bot operator who signs its own zone and the
verifier who chooses to validate. Both control their own end and both want
the outcome. Global signing and validation percentages describe parties who
are not in this transaction.

On Martin's "path to some root": DNSSEC terminates at exactly one root, the
IANA-signed root, which is a cleaner and more auditable trust origin than a
set of independently trusted CAs. For this use case that is a feature, not
a liability.

Where DNSSEC plus DANE actually earns its place is the second function, the
one nobody has proposed a mechanism for. Continuity is a key, agreed. But
tie-back to a real-world operator, the "allow company X's bots, block
company Y's" case, is exactly what the WebPKI cannot give you: a
domain-validated certificate proves control of a name, not who operates it.
The DANE-EE binding the DANCE working group specified for TLS client
identity, certificate usage 3 with an SPKI selector, applies directly to an
HTTP message signature key: publish the key, or its SPKI hash, in a
DNSSEC-signed record under the operator's name, and the verifier learns the
key is bound to that name with a chain to the root and no live fetch. RDAP
then answers the operator-of-record question over that same name in a
standard, queryable way. So the full stack is a key for continuity, DANE-EE
for the domain binding, and RDAP for the real-world tie-back. No WebPKI and
no ledger.

One operational note, since deployment simplicity is on Thibault's list. A
WebPKI-bound directory is a live TLS fetch of a well-known at verification
time, which can be down or interfered with at that moment. A DNSSEC-signed
record is a cacheable, offline-verifiable assertion. For a verifier on a
hot path, that is the simpler and more robust of the two.

So on Thibault's two-mode proposal I am strongly in favour of making the
key-alone and domain-bound modes explicit, and I would ask that we not
pre-close the domain-bound mode on the WebPKI. DANE-EE under DNSSEC, with
RDAP for provenance, is a first-class option for that mode, and for a
server-to-server verifier it is arguably the better-fitting one. I am
bringing a draft to DANCE on exactly this anchoring, and I am happy to
write up the DNS side for the group and to virtually bring it to Vienna.

Kaveh

On Tue, Jul 14, 2026 07:59 PM, Eric Rescorla <[e-mail]> wrote:

> Hi Thibault,
>
> I'd like to try to uplevel a bit and talk about functionality rather
> than mechanism. It seems to me that there are two main things one
> might be trying to do here:
>
> - Continuity of identity for a given bot
> - Tying the identity of a bot back to some other identity, such
>   as a domain name or a real world organization
>
> If what we're interested in doing is building up a reputation for a
> bot, then all we need is continuity of identity, which basically
> means a key. If we didn't need key rotation, then that could plausibly
> be it. If we *do* need key rotation, then we need some way to
> deactivate the superseded keys. In the "key-as-identity" case, this
> is frequently done with some kind of ledger that records the
> supercession.
>
> The reason you need to tie it back to a real-world identity is if you
> want to treat bots with similar behavioral histories differently, for
> instance, because you want to allow some new bot from company X based
> on some external information [0] but not allow new bots from comapny
> Y.
>
> In this particular case, you're tying it back to the (alleged) domain
> name of the bot. At the end of the day this has to be authenticated
> via either the WebPKI or DNSSEC, because those are the only
> technologies that cryptographically authenticate a domain name.
> IMO the WebPKI is the clear winner here, for the reasons MT
> indicates.
>
> -Ekr
>
>
> [0] As I've indicated in previous messages and in
> draft-rescorla-anonymous-webbotauth, I think this level of granularity
> enables a lot of misuse, but let's put that aside for the moment.
>
>
> On Tue, Jul 14, 2026 at 8:35 AM Thibault Meunier <ot-ietf=
> [e-mail]> wrote:
>
>> Hi Martin,
>>
>> Thanks for starting a discussion. If the drafts confuses you, i suspect
>> it confuses others.
>>
>> In term of use cases, the goal is to improve the status quo of IP address
>> and user agent, which don't serve website or bots well. Bots are prone to
>> impersonation, don't enjoy IP mobility, and have a hard time sharing IP
>> address. And for server, they get pretty unreliable information that can be
>> hard to act on.
>>
>> That's the main goal of the draft. Provide a mechanism that preserve the
>> simplicity of usage for bots, and the simplicity of action for websites.
>> When they see a spike in traffic, they can look at their log for IP
>> address/user agent. With httpsig draft, they can look for a keyid.
>>
>> Relisting your two options as to where the anchor lies,
>> draft-meunier-webbotauth-httpsig-protocol targets option 1 with the "key"
>> being represented by a normalised thumbprint.
>>
>> 1. In the key itself.  In this model, a bot chooses a key and proof of
>> control over that key is the ultimate source of truth for that bot.
>> 2. In the Web PKI.  In this case, you probably need to use something like
>> .well-known so that you can be sure that the owner of the domain is taking
>> responsibility.
>>
>> Option 1 still implies the website has access to a (public) key used by
>> the automated client. That's where the directory draft comes in. It
>> provides a discoverability hint via Signature-Agent for the website to
>> retrieve the necessary verification material to verify requests. With
>> option 1, the key could be hosted anywhere, given the key itself is the
>> anchor.
>>
>> Discovery could happen via other mechanisms. The draft aims to facilitate
>> and recommend a mechanism which any bot and any website can use without
>> much infrastructure. In place of Signature-Agent, keys could be discovered
>> via a signature-key that Dick and I are iterating on, the DNS, or other
>> mechanisms that the group deems suitable. Signature-Agent is simply what
>> has worked so far.
>>
>> Then comes key rotation and naming, which I believe are more of option 2.
>> A key is secure and decentralised, but not human readable. A name would be
>> human readable and allow trust to persist across rotation. Is a name
>> required for website to validate a signature: not in the protocol draft,
>> given trust is anchored on the key. An automated client is not expected to
>> have a name. A name does help bots to establish a relationship with sites
>> like they did with IP address lists hosted at a recognisable domains and
>> attached in the User-Agent.
>>
>> For signing, I suspect you refer to Section 5.2. It provides a proof of
>> possession (without recursion), while authority is provided by having a
>> well-known over TLS. This is closer to option 2, but validation does not
>> depend on it.
>> As for the delegation you refer to, I imagine you are refering to
>> Appendix A.2. "It is adviced to consider delegation as experimental for
>> now" was an attempt to say that there are likely ways to delegate, but
>> nothing is settled and probably would be its own document. If that's a
>> source of confusion, happy to remove it in the next iteration.
>>
>> The wording reflects the layering between -protocol that anchors on the
>> key (option 1) while aiming to facilitate discovery with -directory
>> (optional and closer to option 2). It also reflects evolutions that
>> hapenned during deployments. That'd be one place where the opinion of the
>> wg would be valued. Moving from MAY/SHOULD to MUST. Protocol draft could do
>> a better job at highlighting why Signature-Agent is opt-in but helpful to
>> achieve the goal, and directory draft could be more normative as to how
>> binding is performed.
>>
>> If it'd help, I can propose text to make this clearer in the protocol
>> draft, at least on GitHub given we are past submission deadline for IETF
>> 126.
>>
>> Links to the set of drafts, including use cases that were discussed
>>
>> [1]
>> https://datatracker.ietf.org/doc/html/draft-nottingham-webbotauth-use-cases-02
>> [2]
>> https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00
>> [3]
>> https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-directory-00
>>
>> Thibault
>>
>>
>>
>> On Monday, July 13th, 2026 at 22:37, Dick Hardt <[e-mail]>
>> wrote:
>>
>> > Hi Martin
>> >
>> > My take on one of the problems the WG was chartered to do was to enable
>> a bot to prove it is a specific bot so it can be differentiated from other
>> bots and a site can attribute reputation to that bot, and that other bots
>> could not impersonate it.
>> >
>> > A bare key (or in practice a thumbprint aka jkt) is one kind of
>> identifier. It allows a bot to prove it was the same bot in previous
>> interactions, allowing it to earn a reputation and be treated as a "good"
>> bot. Of course a bot can share its key with another bot, and the two bots
>> would be indistinguishable in general -- but that is a related, but
>> different discussion.
>> >
>> > Providing an id that can be resolved to a key, such as a hostname
>> (bot.example) and a .well-known path leading to a jwks_uri and a jwk allows
>> a bot to not only build a reputation, but allows the site to know it is a
>> bot associated with that bot.example and execute policies based on the
>> bot.example identifier.
>> >
>> > I view this as a useful primitive generally on the internet for any
>> http client, and worked with Thibault to create
>> https://datatracker.ietf.org/doc/draft-hardt-httpbis-signature-key/
>> which is a general purpose mechanism for keys to be used with http message
>> signing.
>> >
>> > This has gotten interest in industry with proponents looking to rid the
>> internet of API keys and other shared secrets.
>> >
>> > /Dick
>> >
>> > On Mon, Jul 13, 2026 at 2:33 PM Martin Thomson <[e-mail]>
>> wrote:
>> >
>> > > I've really struggled with this set of drafts. This started with the
>> no-it's-not-an-architecture version, but the problem persists. It's taken
>> me a while to try to work out what it is that is missing. Even then I'm not
>> sure, so this email is an attempt to start a conversation about what we
>> think these drafts are attempting to accomplish and how.
>> > >
>> > > httpsig (a shorthand I'll use for
>> draft-meunier-webbotauth-httpsig-protocol) is all mechanism. There's no
>> discussion of how those mechanisms connect to a purpose at all. The reader
>> is left to infer.
>> > >
>> > > In contrast, Ekr's proposal doesn't suffer from a lack of clarity of
>> purpose. It is pretty clear about what it wants to achieve. In fact, that's
>> the bulk of the proposal, because the nuts and bolts are still being worked
>> out (which is totally fine). It's weakness is that it will take a lot of
>> time to get those technical parts sorted out.
>> > >
>> > > This group has identified a problem in that bot identities today are
>> tied to self-assertions of this weird user-agent string thing ("yes, you
>> can believe me when I say that I'm GoogleBot, really... you gotta believe
>> me... would I lie to you...") or through some sort of fragile IP address
>> thing, where you look at the remote IP address and make some inferences
>> based on that (which might involve databases). There's some virtue in the
>> simplicity of each, but ultimately the situation is that servers get pretty
>> unreliable information that can be hard to act on.
>> > >
>> > > It seems like the main thing you might do, given a hammer that is
>> shaped like a digital signature, is to use that to bind some notion of bot
>> identity to requests. That's what httpsig seems to want to do. But it isn't
>> crisp about what that identity is.
>> > >
>> > > The directory draft (draft-meunier-webbotauth-httpsig-directory)
>> seems to want to use the Web PKI as the target of the binding. Except that
>> it doesn't really do that. It's pretty confusing (or confused, I can't
>> tell) in that it defines a .well-known resource, but also has the ability
>> to point to a resource that contains keys that is hosted anywhere. There's
>> also some signing involved, but I honestly don't know how that doesn't lead
>> to turtles all the way down, where you need another set of signing keys to
>> sign those resources, which then need another directory, and so on
>> endlessly.
>> > >
>> > > It seems to me like there is two obvious ways to anchor bot identity:
>> > >
>> > > 1. In the key itself. In this model, a bot chooses a key and proof of
>> control over that key is the ultimate source of truth for that bot.
>> > >
>> > > 2. In the Web PKI. In this case, you probably need to use something
>> like .well-known so that you can be sure that the owner of the domain is
>> taking responsibility.
>> > >
>> > > In either case, you might layer on delegation, key rotation, and
>> other facilities to make it possible to more easily manage various aspects
>> of key lifecycles (cryptographic agility, safeguards against compromise,
>> rotation, temporary delegation to less-secured entities, etc...). Those are
>> embellishments though. You need to have a clear path to some root.
>> > >
>> > > There are other options, but I can see some pretty gnarly problems
>> with them:
>> > >
>> > > 3. In a URI. The problem here is that URIs are cheap and there's any
>> number of ways to create ways to "control" the representation of a resource
>> on someone else's server. Anchoring this way means that you can't really
>> say much about the controller of the resource; at least not with any real
>> confidence.
>> > >
>> > > 4. In the DNS. This is really not that different from the Web PKI
>> scenario. You might use DNSSEC, if you were happy to ignore its dire
>> deployment status. Whether you do that or not, it's always going to be
>> considerably more difficult to deploy something when the primary usage is
>> in a completely different protocol. Even if you stick with something that
>> is close to HTTP, involving the DNS is going to create real problems in
>> deployment. Getting further away from HTTP is going to compound any issues.
>> > >
>> > > 5. In some distributed consensus protocol. This might be close to
>> anchoring on a key itself or it could be something far, far worse. Lots of
>> options here, but I am not enthusiastic about prospects for good things out
>> the other end.
>> > >
>> > > I don't have a firm opinion on the merits of 1 over 2 or vice versa.
>> Or maybe this will be both, with the bot able to choose the model that
>> suits it. Or maybe the site chooses instead. We need a proposal that has an
>> opinion.
>> > >
>> > > _______________________________________________
>> > > Web-bot-auth mailing list -- [e-mail]
>> > > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> Web-bot-auth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Web-bot-auth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>