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

[Thibault Meunier <[e-mail]>]

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.

> 
> 
> 
> > Then, I think there is a third item which is more of a constraint
> > - Deployment simplicity to allow for incremental adoption. The modification required on the client and the verifier side should be minimal.
> 
> 
> I agree with this.
> 
> > 
> > > 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.
> > 
> > If we do need key rotation, domain binding would also provide it, without a ledger.
> > An old key and a new key can be served at the same time in one directory. Removing a key from the directory deactivates it once cache expires (for verifiers using that binding).
> 
> 
> Right. This kind of mechanism is basically isomorphic to what Dick
> proposed, with the WebPKI certificate acting to endorse the current
> keys and the WebPKI being used to invalidate older signing keys.

This is similar in function. There is a difference as to where the authority lives though. With jkt-jwt, the anchor is
the root key, providing some rotation capabilities for sub-keys, but still making loss or compromise a difficult scenario. So this is closer to the key alone model. With a domain as the anchor (WebPKI in the current draft), the authority is with the controler of the directory endpoint. If you have a loss or compromise, you can update the directory. This is the domain binding model. If you lose the domain, then you lose the attached trust you've built. Both mechanisms are complementary, with jkt-jwt facilitating operation for key-alone model, and domain-binding easing recovery.

> 
> 
> > Because that binding is a domain, it gives verifiers a name to attach
> > information to.
> 
> 
> 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.

Thibault

> 
> -Ekr
>