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

  1. Include @authority (or @target-uri) in the covered components.
  2. If you send a Signature-Agent header, add signature-agent to 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 @authority and @target-uri derived components.
  • The web-bot-auth architecture draft requires at least one of @authority or @target-uri, and signature-agent when 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.