[Web-bot-auth] Vectors reproduced, a note on unnamed failures, and two field observations

[ParallaxGrain <[e-mail]>]

Hi all,

I am an independent researcher and this is my first post here. I have been
following this work since the spring and I run a public verifier for the
protocol, which is where the three results below come from.
On the call for adoption: I support it. I was able to implement from the
published text alone, and the vectors added in -02 made that implementation
checkable rather than merely plausible.

1. The test vectors in draft-meunier-webbotauth-httpsig-protocol-02.

All three EdDSA vectors are wired into my test suite. My verifier rebuilds
each published signature base byte for byte and verifies each published
signature with the RFC 9421 Appendix B.1.4 key. I also regenerated E.2.1's
signature from scratch with the B.1.4 private key and got the published
bytes exactly, so the vectors reproduce end to end and not only under my
own parser.

I independently confirm the defect Joshua reported: E.2.1 keys its
Signature-Agent member agent2 while the signature label is sig2, and the
text requires the member keyed to the signature label to be covered. A
verifier built from the prose alone selects by the signature's own label,
finds nothing, and fails the document's own vector. E.1.1 has the same
shape, I did not run it, as I implement Ed25519 only. E.2.2 is unaffected,
since the legacy form carries no member key. That is #128 in the authors'
repository, and the re-keying Joshua suggested closes it.

The vectors were the most useful addition in -02. Nick's directory vector
in particular gave me something to check the possession proof against,
which the prose alone had not.

2. A rejection has no name (negative test vectors), and that can be
important for the client.

This was the recurring problem while building the verifier. When
verification fails, nothing tells the client which of several unrelated
things went wrong. "My signature base is malformed", "my clock is ahead",
"the verifier never fetched my directory" and "my key is not in it" all
arrive as the same event. None of them can be acted on, and the only way
forward is to guess and retry against a live endpoint.

The document does not fill that in. An origin gets 400, 403 and 429.
Verifier Outcomes gives verified, invalid and unverified, and nothing below
that. The flagship deployment shows the effect: Cloudflare's test endpoint
answers 401 when the key is unknown, and the same page notes you may also
see 401 when the key is known but the message failed to verify. Two
unrelated faults with different fixes, under one code.

My verifier names 36 faults and returns the one that applies, with a
sentence saying what to change. They divide into 19 that mean the request
broke a rule and 17 that mean the verifier could not decide, which is
invalid and unverified one level further down, grouped by what the operator
would have to touch: the signature, the Signature-Agent header, the
directory, the key. The list is at
https://packet.guru/agents/reference#faults

One datapoint on whether the names carry their weight. I pointed an
autonomous agent at that endpoint with nothing but the published guide and
no help from me. It produced a verifying signature and a readable agent
card within a few minutes, correcting itself from the named faults between
attempts. Against a bare 401 it would have had nothing to work from.

#11 asks for negative test vectors and has no comments on it. Writing one
forces this question directly, because a negative vector needs an expected
reason, and today there are only three to choose from. If it is useful I
will prepare a set against the B.1.4 key, one fault per vector, with the
request, the expected outcome and the reason, and the group can keep,
rename or drop any of the names.

3. Two field observations, measured today across the eight distinct
operators publishing a directory.

On alg and #109: two emit EdDSA, six omit the member, and none emit
ed25519, the registered name that applies to an Ed25519 key. Joshua
reported from the signer side that the conformant value is the one stock
WebCrypto refuses to import, and I can confirm that independently:
importing the same JWK with alg absent, or as EdDSA, or as Ed25519,
succeeds, and with ed25519 it is refused. Both resolutions have already
been named on the list, either say "omit it" or align the member with the
JOSE names. I have no third to offer, only the count: whichever way it
goes, one of those two already matches every deployment I can see, and the
value in the text matches none of them.

On purpose: the registry draft defines it as a card parameter and leaves
the vocabulary open, with AIPREF named as a candidate and search as the
example. On the list the current answer for distinguishable per-purpose
crawlers is a distinct URL per purpose, which Shivdeep and Joshua have both
described from their own deployments. Meanwhile two production key
directories already carry a purpose member in the directory itself:
chatgpt.com sends "ai" and browserbase.com sends "rag". RFC 7517 says
additional members in a JWK Set must be ignored if not understood, so
neither is malformed. But they are two different words for the same slot,
chosen with nothing to choose from. If the vocabulary question is still
open, those are two live values to test a candidate against.

Thanks for the work on this. I hope some of it is useful, and I am happy to
help where I can.