The keyid parameter

Originally submitted by Takahiko Kawasaki (Takahiko Kawasaki) on 2024-10-07

It seems preferable to recommend including the keyid parameter (RFC 9421 HTTP Message Signatures, Section 2.3. Signature Parameters) to the signature metadata of HTTP message signatures.

When used with the mandatory created and tag parameters, the keyid parameter will appear in the Signature-Input HTTP field as shown below.

GET /api/userinfo HTTP/1.1
Host: trial.authlete.net
User-Agent: curl/8.7.1
Accept: */*
Authorization: Bearer 4rSgHO6sdlBL4z_1l4bAmED2CG40zblXlc3YDqrqdu8
Signature-Input: sig=("method" "target-uri" "authorization")\
 ;created=1728051074\
 ;keyid="ScIdKFzAj93vywpwjrfi3wrj5oHmHbHfmPT5IPTLmVc"\
 ;tag="fapi-2-request"
Signature: sig=:yx+SthCcbAu7R7rV1DoZX8ILLURmHwNTlRXMbnJVRHWXwyHQQPmPnLLhNx9tHeqG8Mp1SeN4CSB38QDwKfkkqA==:

The reason for recommending the use of keyid is that it is the only vendor-neutral means for key identification.

Without the keyid parameter, the resource server’s implementation would have to identify the key based on its own custom rules, significantly reducing interoperability. As a result, fintech client applications would need to agree on different key identification methods for each finantial institution they communicate with. Additionally, without the keyid parameter, while not impossible, it would become considerably difficult to support the use case mentioned in the first paragraph of RFC 9421 HTTP Message Signatures, Section 4.3. Multiple Signatures, where “a signer may include multiple signatures signing the same message components with different keys or algorithms to support verifiers with different capabilities.”

‌

Bitbucket status: open

Bitbucket origin: issue 721

Start with RFC 9421 Sections 2.3 and 4.3, then trace the FAPI text and examples affected by HTTP message-signature metadata. Confirm how recommending keyid affects interoperability and multiple signatures; done means the relevant FAPI guidance and examples clearly specify the recommendation.