[Openid-specs-fapi] Issue #721: The keyid parameter (openid/fapi)

[Takahiko Kawasaki]

New issue 721: The keyid parameter
https://bitbucket.org/openid/fapi/issues/721/the-keyid-parameter

Takahiko Kawasaki:

It seems preferable to recommend including the `keyid` parameter \([RFC 9421 HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421.html), [Section 2.3. Signature Parameters](https://www.rfc-editor.org/rfc/rfc9421.html#section-2.3)\) 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](https://www.rfc-editor.org/rfc/rfc9421.html#section-4.3), where _“a signer may include multiple signatures signing the same message components **with different keys** or algorithms to support verifiers with different capabilities.”_

‌