Required components covered

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. The protocol draft (draft-ietf-webbotauth-httpsig-protocol-00, section 5.2) requires at least one of two components: @authority (the request’s host and port) or @target-uri (the full request URL).

Every signed request also carries a Signature-Agent header, and the member keyed to the signature label must be covered as a component (section 5.2.1). The draft’s minimal set is:

("@authority" "signature-agent";key="sig1")

This check reads the covered set from Signature-Input and confirms:

1. @authority or @target-uri is in it.
2. signature-agent is in it, whenever the request carries a Signature-Agent header.

A missing component fails the check. When the header itself is missing, the Signature-Agent check fails once for that, and this check does not report it a second time.

The check does not require the member key to equal the signature label. The draft’s own test vector signs under the label sig2 and covers the member agent2 (Appendix E.2.1).

When the signature covers a dictionary member ("signature-agent";key="sig1"), the value that goes into the signature base is that member’s value serialized as a structured field, including its parameters (RFC 9421, section 2.1.2). For sig1="https://example.com/jwks.json";type=jwks_uri the base line is:

"signature-agent";key="sig1": "https://example.com/jwks.json";type=jwks_uri

Why it matters

A signature only protects what it covers. If neither @authority nor @target-uri is covered, 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.

signature-agent matters for the same reason. The header tells a verifier where to fetch your keys. Left uncovered, it can be swapped to point at a directory someone else controls while the signature still checks out.

How to fix it

1. Include @authority (or @target-uri) in the covered components.
2. Send Signature-Agent and cover it. For the dictionary form, cover the member keyed to your signature label:

Signature-Agent: sig1="https://example.com"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=...;expires=...;keyid="...";tag="web-bot-auth"

For the legacy string form, cover the whole header:

Signature-Agent: "https://example.com"
Signature-Input: sig1=("@authority" "signature-agent");created=...;expires=...;keyid="...";tag="web-bot-auth"

Which form to send is a trade-off between the draft and the verifiers you need to reach; the Signature-Agent check explains it.

Whatever you cover here must match what goes into the signature base when the request is signed; a mismatch shows up as a verification failure rather than a covered-components failure. Verifying a signature that covers @target-uri requires the full request URL; the verify page has an optional Request URL field for that.

The draft also lists components that narrow a signature to one request, such as @method and @path (section 5.2). They are optional, and this check does not require them.

References

• The Web Bot Auth protocol draft (draft-ietf-webbotauth-httpsig-protocol-00): section 5.2 requires @authority or @target-uri, and section 5.2.1 requires the Signature-Agent member to be covered.
• RFC 9421 defines covered components, the @authority and @target-uri derived components, and the key parameter for dictionary members (section 2.1.2).
• How grading works explains how a missing required component affects the grade.