Required components covered
Signature-Input must cover @authority or @target-uri, and signature-agent too whenever a Signature-Agent header is sent.
What this check verifies
The parenthesised list at the start of Signature-Input names the covered components: the parts of the request the signature commits to. For the web-bot-auth profile the architecture draft requires at least one of two components: @authority (the request’s host and port) or @target-uri (the full request URL). Earlier draft versions required exactly @authority; since draft -05, @target-uri is a valid replacement.
signature-agent is required only when you send a Signature-Agent header. The draft puts it this way: if the header is to be sent, one of its members MUST be signed as a component. So the rule is conditional. No header, no requirement; header present, the component must be covered.
This check reads the covered set from Signature-Input and confirms @authority or @target-uri is there. If the request also carries a Signature-Agent header, it confirms signature-agent is covered as well. A missing required component fails the check.
Covered components may carry parameters. The current dictionary form of Signature-Agent is covered with a key parameter naming the dictionary member:
Signature-Input: sig2=("@authority" "signature-agent";key="agent2");created=...;keyid="...";tag="web-bot-auth"
Why it matters
A signature only protects what it covers. If neither @authority nor @target-uri is in the covered set, the signature says nothing about which host the request was aimed at, so a captured signature could be replayed against a different origin and still verify. Covering one of them binds the signature to the intended target.
signature-agent matters for the same reason. The header tells a verifier where to fetch your keys. If you send it but leave it uncovered, an attacker can swap the header to point at a directory they control while the signature still checks out, which defeats the point of naming the directory.
How to fix it
- Include
@authority(or@target-uri) in the covered components. - If you send a
Signature-Agentheader, addsignature-agentto the covered list too. The two go together: send the header and cover it, or send neither.
A correct minimal list with no Signature-Agent header:
Signature-Input: sig1=("@authority");created=...;keyid="...";tag="web-bot-auth"
With a dictionary-form Signature-Agent header:
Signature-Input: sig2=("@authority" "signature-agent";key="agent2");created=...;keyid="...";tag="web-bot-auth"
Whatever you cover here must match what is fed into the signature base when the request is signed; a mismatch shows up as a verification failure rather than a covered-components failure. Note that verifying a signature that covers @target-uri requires the full request URL; on the verify page there is an optional Request URL field for exactly that.
References
- RFC 9421 defines covered components, including the
@authorityand@target-uriderived components. - The web-bot-auth architecture draft requires at least one of
@authorityor@target-uri, andsignature-agentwhen the header is sent. - How grading works explains how a missing required component affects the grade.
How the checker scores this
- Tier
- Signature
- Role
- Advisory. Failing this never caps the grade or changes the verdict.
- Point deduction
- A failure deducts 30 points; a warning deducts 8.