DKIM2-Signature: i=1; m=1; t=1791419054; d=mnot.net;
	mf=PG1ub3RAbW5vdC5uZXQ+; rt=PHdlYi1ib3QtYXV0aEBpZXRmLm9yZz4=;
	s=fm3:rsa-sha256:KT2m5U7iUbuEFvGwLAqoqWS+a7l6HCtEfKJfne0nHQLyM3E
	c+WC5uuQbolzM2EGxrkjoLcFbL1kQDKsFOxEy4tSvYi7vG2TuIGHJq+UzU14WTyP
	U1Bgreyzh8tHkzaA8XrcwpLruxlILA2Z/Uk6x6c1q/zTNUui/Z6kyrKiYCC4EqQV
	WvXbO7/5uwU/Ri1v+JeI6maewFL2FdC4FjZObFYFwRWrPUAVA8lTtcTe9keGK/kZ
	7wYC1HXY0dRNf9p9APR0pI/BTNmkBWZzRZRpxoS8JHbugXjSZYvwwJW8HEpuhA6P
	MLxKRiSDTda1N5F4YspQq0hUEU8AAVDk5KfA1yw==;
Message-Instance: m=1;
 h=sha256:FZbD+6s8wBnlnSfLYmXWOeKi/xEjrvAJ1ydtp+WByNI=:b4/mCDujzQoXu7DrZrdB+DmwkKS6s+wBatrEPoe3cVk=;
Feedback-ID: ie6694242:Fastmail
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.100.1.1.11\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: 
 <-5_euDtYce1o5FwjXLUXtkFNPxxVrDY8GOSQlmXWZcCyTp_h0IDnlyo5Jxf9na7_kw-eQ8kNXE9Xk7I2oExDuT0cDqnu6StnW9AqDehhkOE=@thibault.uk>
Date: Thu, 8 Oct 2026 11:24:10 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D096E61-4131-46D4-920C-8E03DE6E572D@mnot.net>
References: <D481972A-8729-4281-97B8-EA65B5BDE82A@mnot.net>
 <-5_euDtYce1o5FwjXLUXtkFNPxxVrDY8GOSQlmXWZcCyTp_h0IDnlyo5Jxf9na7_kw-eQ8kNXE9Xk7I2oExDuT0cDqnu6StnW9AqDehhkOE=@thibault.uk>
To: Thibault Meunier <ot-ietf@thibault.uk>
Message-ID-Hash: X2NEFAT36Q73S34QQDPTAUDQOEJINPB5
CC: web-bot-auth@ietf.org
Precedence: list
Subject: [Web-bot-auth] Re: Jumping on the bandwagon: Implementation Report(s)
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/web-bot-auth/fDM_deEVKXJLjgbM83YKAgFfEfc>

Hi Thibault,

> On 8 Oct 2026, at 4:19=E2=80=AFam, Thibault Meunier =
<ot-ietf=3D40thibault.uk@dmarc.ietf.org> wrote:
[...]
> Would the following under 5.3 Requesting a message signature work?
>=20
> """
> - An Origin MAY choose to request signatures from clients that did not =
initially provide them.
> + An Origin that expects a signature SHOULD request one from clients =
that did not provide it.
> """
>=20
> In addition to simplifying 6.11 Unsigned request, we could have a =
short paragraph in Appendix C on Deployment guidance
>=20
> """
> C.XX Signing conditionally
>=20
> Agents can sign every request, or only when an origin requests a =
signature ({{requesting-message-signature}}). Signing only when an =
origin asks for it adds a round trip, and non-idempotent requests may =
not be safely retried.
> """

Looks good, but probably something like "... and non-idempotent requests =
cannot be automatically retried without additional protocol mechanisms; =
see {{Section 9.2.2 of HTTP}}."

Something like this might also help in 5.3:

"""
An Origin can refuse requests that do not have valid signatures with an =
appropriate HTTP status code; usually 403 (Forbidden), per Section =
15.5.4 of [HTTP]. When doing so, the Origin SHOULD include the =
Accept-Signature field (Section 5 of [HTTP-MESSAGE-SIGNATURES]) to =
indicate what signatures would result in the request being accepted.=20

An Origin can also still accept requests that do not have valid =
signatures, but indicate that the result would be different if one were =
present by sending the Accept-Signature field in the successful =
response.

Origins that do not send Accept-Signature in either of these cases =
SHOULD NOT rely on the presence of signatures in requests unless there =
is a private arrangement between both parties to do so. Such =
arrangements need to specify when and how signatures are sent in detail.
"""


> I'd be interested to hear more, if you have time. While the protocol =
has not changed _much_, there are some changes and being able to track =
deployment would be useful. I'm not sure how to best to that beyond =
asking folks what they've deployed and tracking requests that are =
received, infering the draft version.
>=20
> There might be space for an error header "it seems you sent me a =
signature. i could not verify it. this is is why".

Maybe. Or <https://www.rfc-editor.org/info/rfc9457/>.

Cheers,

--
Mark Nottingham   https://mnot.net/