Podpisy wiadomości HTTP (RFC 9421)

Przez dwadzieścia lat web miał problem z autoryzacją żądań HTTP. Basic Auth z 1999 roku przesyłał hasła w base64 — funkcjonalnie plaintext. OAuth 1.0 z 2010 wprowadził podpisy oparte na HMAC, ale każdy provider implementował to inaczej. AWS Signature v4 dla S3, Google z własną składnią, Twitter wymagający swojego custom flow — każda duża platforma wymyślała własne podpisywanie żądań. Programiści integrujący wiele API musieli pisać kod podpisywania od zera dla każdej platformy. W lutym 2024 IETF opublikowało RFC 9421 — HTTP Message Signatures. Jeden standard, formalna procedura, IETF-endorsed. Czym jest HTTP Message Signatures (RFC 9421) HTTP Message Signatures (RFC 9421) to standard IETF definiujący jak podpisywać wybrane komponenty wiadomości HTTP — metodę, URL, nagłówki, treść — kryptograficznie przy użyciu pary kluczy publiczny/prywatny. Standard zastąpił wcześniejsze draft-cavage-http-signatures które krążyły w branży przez dekadę bez formalnego statusu. Zalecane algorytmy: ed25519, ecdsa-p256-sha256, rsa-pss-sha512. Jak to działa technicznie Nadawca wybiera które komponenty wiadomości chce zabezpieczyć. Typowy zestaw dla żądania API: metoda HTTP, URL targetu, nagłówek host, content-digest treści. Z tych komponentów buduje signature base — kanoniczny string łączący wszystkie wybrane wartości w ustandaryzowany sposób. Podpisuje signature base kluczem prywatnym używając wybranego algorytmu (najczęściej ed25519). Wynik dołącza do żądania w dwóch nagłówkach. Signature-Input zawiera listę komponentów które zostały podpisane plus metadane (algorytm, key id, expires). Signature zawiera sam podpis kryptograficzny. Odbiorca rekonstruuje signature base z otrzymanego żądania używając informacji z Signature-Input — wie dokładnie które komponenty były podpisywane i w jakiej kolejności. Pobiera publiczny klucz nadawcy z key id reference. Weryfikuje podpis kryptograficznie. Jeśli żądanie zostało zmodyfikowane w drodze — inna URL, dodany nagłówek, zmieniona treść — signature base się nie zgadza i weryfikacja fail. Co odróżnia RFC 9421 od poprzednich prób Wcześniejsze próby standardyzacji (draft-cavage 2013-2019) krążyły w stanie roboczym ale nigdy nie osiągnęły statusu RFC. Implementacje były niespójne, mechanizm definicji komponentów niejasny, brak konsensusu na algorytmy. RFC 9421 rozwiązuje to przez formalny status IETF, jasną definicję mechanizmu derived components (jak rozróżnić target-uri vs scheme vs authority), wskazane algorytmy oraz pełen test suite. To pierwszy RFC w tej przestrzeni który ma realny adoption pace. Zastosowania w Agentic Web Web Bot Auth używa RFC 9421 jako fundamentu. Cloudflare, Akamai i AWS WAF implementują weryfikację bezpośrednio w warstwie CDN — strona pod ich infrastrukturą dostaje weryfikację za darmo bez konieczności implementacji własnej. Google-Agent podpisuje swoje żądania zgodnie z RFC 9421, publikując publiczny klucz pod https://agent.bot.goog. Visa Trusted Agent Protocol (TAP) i Mastercard Agent Pay używają tej samej bazy do weryfikacji tożsamości agenta przy transakcjach finansowych. Verifiable Credentials transport (W3C) wskazuje RFC 9421 jako jedną z dopuszczalnych metod przesyłu poświadczeń. HTTP Message Signatures a właściciel strony Dla webmastera RFC 9421 to fundament pod warstwę logiczną. Jeśli używasz Cloudflare, Akamai lub AWS WAF — weryfikacja jest po stronie CDN, nic do wdrożenia. Jeśli chcesz mieć granularną kontrolę po stronie origin (np. różne traktowanie zweryfikowanego Google-Agent vs nieznanego bota) — biblioteki do weryfikacji RFC 9421 są dostępne dla wszystkich popularnych języków: Node.js, Python, Go, Rust, PHP. Praktycznie: nie musisz znać szczegółów RFC żeby z niego korzystać. Wystarczy zrozumieć że wszystkie nowsze mechanizmy weryfikacji agentów — Web Bot Auth, Agent Name Service, KYA, Visa TAP — leżą na tej samej kryptograficznej bazie.