HTTP Message Signatures (RFC 9421)

HTTP Message Signatures nedir

HTTP Message Signatures, bir HTTP isteği veya yanıtının belirli bölümleri üzerinde dijital imzalar oluşturmak ve doğrulamak için kullanılan bir IETF standardı olan RFC 9421 içinde tanımlanır. Bir istemci, hangi bileşenlerin kapsanacağını seçer (örneğin method, target URI, authority ve seçili headers), bunlardan kanonik bir signature base oluşturur ve bunu bir private key ile imzalar. Sonuç iki header içinde taşınır: Signature-Input (Section 4.1), kapsanan bileşenleri ve created, expires, keyid ve alg gibi parametreleri listeler, ayrıca Signature (Section 4.2), signature değerinin kendisini taşır. Her ikisi de RFC 9651'in Structured Field Values sözdizimini kullanır.

Alıcı, aslında aldığı isteğe göre aynı signature base'i (Section 2.5) yeniden oluşturur, keyid tarafından referans verilen public key'i arar ve imzayı kontrol eder. İmzanın kapsadığı herhangi bir şey aktarım sırasında değiştiyse doğrulama başarısız olur.

Neden app'ler, APIs ve MCP server'lar için önemlidir

Çoğu otomatik trafik, kendini bir user-agent string veya kendi seçtiği bir client adıyla tanımlar. İkisi de kolayca kopyalanabilir. Message signature farklıdır: bir isteği bir anahtara bağlar ve yalnızca private key sahibi geçerli bir imza üretebilir. Crawler'lar, assistant'lar ve autonomous agent'lar tarafından gelen trafiği alan bir application için bu, "bu client kendisinin X olduğunu söylüyor" ifadesini "bu istek, X'in yayımladığı anahtar tarafından imzalandı" ifadesine dönüştürür.

Bu ayrım, iş birliği yapan otomatik client'ları anonim trafik yerine bilinen katılımcılar olarak ele almanın temelidir. Bir API'nin imzalı bir crawler'ı yapılandırılmış bir endpoint'e yönlendirmesine, bilinen bir operatöre farklı bir rate limit uygulamasına veya bir MCP server'a bir tool çağıran taraf hakkında daha fazla bağlam sağlamasına olanak tanır.

Doğrulama pratikte nasıl çalışır

1. Signature-Input ve Signature'i ayrıştırın ve beklenen bileşenlerin kapsandığını doğrulayın. Kullanışlı hiçbir şeyi kapsamayan bir imza çok az şey kanıtlar.
2. Gecikmiş veya yeniden oynatılmış istekleri, toleransınız içinde reddetmek için created ve expires parametrelerini kontrol edin (signature replay hakkında Section 7.2.2 bölümüne bakın).
3. keyid'i, operatörün bilinen bir konumda yayımladığı bir key directory gibi güvendiğiniz bir kaynaktan public key'e çözün. IETF Web Bot Auth protocol draft, otomatik client'lar için böyle bir directory tanımlar.
4. Signature base'i tam olarak belirtildiği şekilde yeniden oluşturun ve declared algorithm ile doğrulayın.
5. Neyin doğrulandığını ve hangi bağlamda doğrulandığını kaydedin, böylece sonraki kararlar buna atıfta bulunabilir.

Production ortamında, el yapımı parsing yerine bakımı yapılan bir RFC 9421 implementasyonu kullanın: canonicalization ayrıntılarını yanlış yapmak kolaydır. signed AI agent requests nasıl doğrulanır rehberi, her adımı kodla birlikte anlatır.

Geçerli bir imza neyi kanıtlar, neyi kanıtlamaz

Geçerli bir imza, isteğin bir anahtar tarafından imzalandığını ve anahtar bir domain altında yayımlanıyorsa isteğin o domain'in operatörüyle ilişkili olduğunu kanıtlar. Şunları kanıtlamaz:

• operatörün dürüst olduğunu veya eylemin güvenli olduğunu,
• bir kişinin isteği yönlendirdiğini veya onayladığını (bkz. delegated authority),
• client'in istediği şeyi yapmaya yetkili olduğunu (bkz. agent authorization).

Kimlik kanıtı ve yetki ayrı sorulardır. Uygulamanızın kendi authentication ve authorization mekanizmaları hâlâ bir client'in ne yapabileceğine karar verir. signed AI agent requests neyi kanıtlar, neyi kanıtlamaz başlıklı blog yazımız bunu daha ayrıntılı ele alır.

Yaygın yanlış kanılar

• "Signed ise güvenilirdir." Signed, atfedilebilir demektir. Trust, atfedilen taraf hakkında verdiğiniz bir policy kararıdır.
• "Signature'lar API keys'in yerini alır." Farklı bir soruya yanıt verirler. Bir API key, hangi account'un çağrı yaptığını söyler; bir signature, isteği hangi client'in ürettiğini söyler. Birçok deployment her ikisinden de fayda görür.
• "İmzalanmamış trafik kötü niyetlidir." Bugün otomatik trafiğin çoğu imzasızdır. Eksik signature'lar, belirlenebilecek şeyleri azaltır, daha fazlasını değil. Bu yüzden Unknown birinci sınıf bir sonuçtur.

Proof of Actor signature'ları nasıl ele alır

Proof of Actor içinde, yayımlanmış bir anahtara karşı doğrulanan bir signature, tam olarak kontrolün ortaya koyduğu kapsam için - yani anahtar ve ona ait identifier - verified basis'iyle kaydedilir. Ortaya çıkan class (genellikle Agent) hiçbir zaman authorization anlamına gelmez. Sonuçlar, analiz için Understand'e ve kendi policies'inizin imzalı bir client'in yapılandırılmış bir yol, farklı bir limit veya hiç değişiklik alıp almayacağına karar verdiği Route'a aktarılır. Web Bot Auth gibi signed-agent standartları gelişmektedir ve Proof of Actor, signed request'leri bu standartlar olgunlaştıkça doğrulamak için tasarlanmıştır.

Evidence'in neyi ortaya koyabileceği hakkında daha fazlasını okuyun veya erken erişim için başvurun.

Kaynaklar

• RFC 9421: HTTP Message Signatures: signature bileşenlerini, parametreleri ve doğrulamayı tanımlayan IETF standardı
• RFC 9651: Structured Field Values for HTTP: Signature-Input ve Signature sözdizimi
• draft-ietf-webbotauth-httpsig-protocol: RFC 9421'i otomatik client'lara uygulayan IETF Web Bot Auth taslağı (November 2026 itibarıyla çalışma aşamasında)