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

[Eric Rescorla <[e-mail]>]

On Thu, Jul 16, 2026 at 2:57 AM Thibault Meunier <[e-mail]>
wrote:

>
>
>
> On Wednesday, July 15th, 2026 at 23:30, Eric Rescorla <[e-mail]>
> wrote:
>
> >
> >
> > On Wed, Jul 15, 2026 at 2:55 AM Thibault Meunier <[e-mail]>
> wrote:
> >
> > > replying inline.
> > >
> > > On Tuesday, July 14th, 2026 at 20:59, 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
> > >
> > > Two things I'd change here. First, I believe that we want continuity
> without pre-established relationship.
> >
> >
> > I don't disagree, but doesn't basically anything do this?
>
> I agree that everything that has been proposed does that. Given this is a
> list of things we are trying to do, I think it's worth adding. For
> instance, out-of-band exchanges (preshared key, allowlisting) are not
> things we should require.
>

Well, we're not drafting a document right now, but rather trying to map out
the space. For that I find it most useful to try to separate questions into
objectives (what the mechanism tries to accomplish) and constraints
on that mechanism. You've listed one here, but it should also be efficient,
secure, etc. Those constraints are going to be crosscutting for all the
objectives and so I don't think it's helpful to list them as if they were
parallel; they are not alternatives.


> Well, it need not. For instance, you could advertise a key with a URL
> > to an object on Google drive that contains keys.json. This wouldn't
> > be Google endorsing the key and doesn't reveal the user's identity.
> > This would still allow for rotation.
>
> Agree. A drive url or random.example are names and give you continuity and
> rotation. A name allows information to be attached. Then it's up to
> verifier to use that information, or not. When that name is a domain with a
> well-known, the keys are attributable to the operator of the domain. On the
> contrary, a drive url should not be attributed to google (without out of
> band communication). From a verifier's perspective, a drive url would be
> closer to key-alone construction, providing a rotation mechanism.


I don't really think it's that helpful to think of these both as *names* in
a practical sense. Going back to my initial taxonomy, there are two things
we can do here, stated slightly differently.

- Bind authentication to some opaque value which is not mapped
  to any other external identity.
- Bind authentication to an identifier which is bound to some external
  identity.

Non-rotatable keys, keys signed by some root key, rotatable keys with
rotation stored in the ledger, keys stored in opaque URLs that aren't
attributable to the domain name (e.g., google drive) are all variants of
this same basic idea. You know someone is talking to you but you don't
know their identity.

By contrast, proposals where the key is stored in DNS or in /.well-known
bind authentication to the domain name, which, by convention, is
a real-world identity [0]. I recognize that this *looks* similar to an
arbitary URL that stores the keys, but it's actually semantically quite
different.

-Ekr

[0] What I mean here is we have a whole infrastructure buiilt up to
let you discover the mapping between domain names and real
world identities; for instance, you can search for "ExampleCo"
and see what result you get.