Skip to main content

6.4. HTTP Signature Derived Component Names Registry

6.4. HTTP Signature Derived Component Names Registry​

This document defines a method for canonicalizing HTTP message components, including components that can be derived from the context of the target message outside of the HTTP fields. These derived components are identified by a unique String, known as the component name. Component names for derived components always start with the "at" (@) symbol to distinguish them from HTTP field names. IANA has created and now maintains a new registry titled "HTTP Signature Derived Component Names" to record and maintain the set of non-field component names and the methods used to produce their associated component values. Initial values for this registry are given in Section 6.4.2. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy [RFC8126].

The DE is expected to do the following:

  • Ensure that the name follows the template presented in Section 6.4.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function.

  • Ensure that the component value represented by the registration request can be deterministically derived from the target HTTP message.

  • Ensure that any parameters defined for the registration request are clearly documented, along with their effects on the component value.

The DE should ensure that a registration is sufficiently distinct from existing derived component definitions to warrant its registration.

When setting a registered item's status to "Deprecated", the DE should ensure that a reason for the deprecation is documented, along with instructions for moving away from the deprecated functionality.

Last updated on