Re: New I-D: draft-hardt-httpbis-signature-key-00 (HTTP Signature-Key Header)

On Thu, Jan 8, 2026 at 10:00 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Thu, Jan 8, 2026, at 21:44, Dick Hardt wrote:
> > A jwk uses base64url encoding -- so converting jwk to / from hwk
>
> Why would you convert when you can include the JWK in the header?
>

Are you conflating a JWK with a JWT?

The Header Web Key (hwk) scheme is a representation of the properties of a
JWK as a structured header.

(looking over the draft, I see this is not in the current draft -- it was
in earlier versions -- will fix)

An example JWK

        {
            "kty": "OKP",
            "crv": "Ed25519",
            "x": "HiC5yH9-fKgeU1b9eV1lG0asCFECrlCXyOu0cg39HNk"
        }

The same key using the hwk scheme

Signature-Key:
sig=hwk;kty="OKP";crv="Ed25519";x="HiC5yH9-fKgeU1b9eV1lG0asCFECrlCXyOu0cg39HNk"

The value of "x" in the JWK is a base64url value. As popular libraries emit
and consume JWK format keys. and not hwk, I expect implementations to be
converting between jek and hwk. If all the parameter values in the
structured headers are strings, it is a simple conversion for all types of
keys (different key types have different properties).  Requiring
implementations to know which properties are base64url and convert those to
base64 (or vice versa) seems error prone and in my opinion outweighs the
advantages of the structured header parser knowing the value is a byte
sequence encoded as base64.