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

[Blake Morrison <[e-mail]>]

Agreed, "why not both" dodges it. 

Higher-layer continuity across key rotation doesn't need a name. A root key
signing short-lived subkeys (as Dick's jkt-jwt does) gives rotation while
the anchor stays an opaque key with no domain in the picture. So only the
second reason forces the binding, blessing a key with reputation that
already attaches to a name a verifier can look up.

That collapses the decision. Key-alone is the floor and carries continuity,
rotation included. The domain layer is required exactly when the verifier's
decision consumes something the key can't carry itself; external reputation
held against that name. Not a default of both, but rather a trigger.

Blake


On Tuesday, 21 July 2026 at 12:08 AM, Martin Thomson <[e-mail]> wrote:

> I'm not sure that "why not both" is the answer here.  Can we make a decision?
> 
> As noted, the purpose of binding to a real-world identity is to either enable a higher-layer continuity (for key rotation) or to bless a key pair with some existing reputation.  It would be really good if we could work out what the principles are behind that decision can be articulated?
> 
> --
> 
> I see something interesting in your text:
> 
> > The binding is not exclusive: several domains may publish the same key.
> 
> Your "I am Spartacus"[1] defenses in the directory draft seem a bit unwieldy.  Are they really necessary?
> 
> [1] https://knowyourmeme.com/memes/i-am-spartacus
> 
> On Fri, Jul 17, 2026, at 09:14, Thibault Meunier wrote:
> > Following this thread, I started laying out a "trust model" section in
> > the protocol draft, prompted by Martin's original email. This thread
> > has helped a lot to sharpen it, and i've reused some of the modelling
> > and wording that came from this discussion (opaque
> > value/external-binding from ekr, key on a domain being distinct from
> > endorsement from Dick).
> >
> > You can see the new section in a rendered protocol draft [1] at the
> > below URL (given the submission window has passed)
> > https://thibmeu.github.io/http-message-signatures-directory/protocol-trust-model/draft-meunier-webbotauth-httpsig-protocol.html#name-identifiers-and-trust-model
> >
> > Beyond the new section, the PR also tightens the directory draft [2] by
> > removing parts which have not seen adoption in deployments such as the
> > delegation examples, and add a MUST for verifiers that rely on domain
> > binding.
> >
> > This proposal does not settle if the current draft makes the right
> > split with two modes. The goal is for it to help better inform the
> > discussion in Vienna.
> >
> > While there is a PR open [104], I believe that it's best to keep
> > comments on the list.
> >
> > [1]
> > https://thibmeu.github.io/http-message-signatures-directory/protocol-trust-model/draft-meunier-webbotauth-httpsig-protocol.html
> > [2]
> > https://thibmeu.github.io/http-message-signatures-directory/protocol-trust-model/draft-meunier-webbotauth-httpsig-directory.html
> > [104]
> > https://github.com/thibmeu/http-message-signatures-directory/pull/104
> >
> > Thanks,
> > Thibault
> >
> >
> >
> > On Thursday, July 16th, 2026 at 18:44, Thibault Meunier
> > <ot-ietf=[e-mail]> wrote:
> >
> >>
> >>
> >>
> >> On Thursday, July 16th, 2026 at 14:38, Eric Rescorla <[e-mail]> wrote:
> >>
> >> >
> >> >
> >> > 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.
> >>
> >> Fair. That's a good split. "no pre-established relationship", similar to security, efficiency, and others, is a constraint, crosscutting both of the objectives
> >>
> >> > 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.
> >>
> >> I really like the term "opaque value". That's better than "key-alone" to qualify the model.
> >>
> >> >
> >> > 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.
> >>
> >> Agree. The URL shape is not what differentiate the opaque and the domain-bound model.
> >>
> >> >
> >> > -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.
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> 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]
>