2. HTTP Message Components

2. HTTP Message Components

In order to allow signers and verifiers to establish which components are covered by a signature, this document defines component identifiers for components covered by an HTTP message signature, a set of rules for deriving and canonicalizing the values associated with these component identifiers from the HTTP message, and the means for combining these canonicalized values into a signature base.

The signature context for deriving these values MUST be accessible to both the signer and the verifier of the message. The context MUST be the same across all components in a given signature. For example, it would be an error to use the raw query string for the @query derived component but combined query and form parameters for the @query-param derived component. For more considerations regarding the message component context, see Section 7.4.3.

A component identifier is composed of a component name and any parameters associated with that name. Each component name is either an HTTP field name (Section 2.1) or a registered derived component name (Section 2.2). The possible parameters for a component identifier are dependent on the component identifier. The "HTTP Signature Component Parameters" registry, which catalogs all possible parameters, is defined in Section 6.5.

Within a single list of covered components, each component identifier MUST occur only once. One component identifier is distinct from another if the component name differs or if any of the parameters differ for the same component name. Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct, such as "foo";bar and "foo";baz. The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks. That is to say, "foo";bar;baz cannot be in the same message as "foo";baz;bar, since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form.

The component value associated with a component identifier is defined by the identifier itself. Component values MUST NOT contain newline (\n) characters. Some HTTP message components can undergo transformations that change the bitwise value without altering the meaning of the component's value (for example, when combining field values). Message component values therefore need to be canonicalized before they are signed, to ensure that a signature can be verified despite such intermediary transformations. This document defines rules for each component identifier that transform the identifier's associated component value into such a canonical form.

The following sections define component identifier names, their parameters, their associated values, and the canonicalization rules for their values. The method for combining message components into the signature base is defined in Section 2.5.