Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

The keyid parameter

Aperta
#709 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Ambito
api, security

Direzione di ricerca

Inizia con le sezioni 2.3 e 4.3 di RFC 9421, quindi esamina il testo e gli esempi FAPI interessati da HTTP message-signature metadata. Conferma in che modo la raccomandazione di keyid influisce sull’interoperabilità e sulle firme multiple; il lavoro è completato quando le indicazioni e gli esempi FAPI pertinenti specificano chiaramente la raccomandazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

component: HTTP Signing migrated-from-bitbucket priority: major type: proposal

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

Lingua principale
HTML
Stelle
4
Fork
3
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openid/fapi

Tutte le issue di openid/fapi

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.