HTTP Message Signatures (RFC 9421)

HTTP Message Signatures क्या हैं

HTTP Message Signatures को RFC 9421 में परिभाषित किया गया है, जो HTTP अनुरोध या प्रतिक्रिया के कुछ हिस्सों पर डिजिटल हस्ताक्षर बनाने और सत्यापित करने के लिए एक IETF मानक है। क्लाइंट चुनता है कि किन घटकों को शामिल करना है (उदाहरण के लिए method, target URI, authority और चुने हुए headers), उनसे एक canonical signature base बनाता है, और उसे private key से sign करता है। परिणाम दो headers में जाता है: Signature-Input (Section 4.1), जिसमें covered components और created, expires, keyid तथा alg जैसे parameters सूचीबद्ध होते हैं, और Signature (Section 4.2), जो स्वयं signature value को वहन करता है। दोनों RFC 9651 की Structured Field Values syntax का उपयोग करते हैं।

प्राप्तकर्ता उस अनुरोध से, जो वास्तव में उसे मिला था, वही signature base (Section 2.5) फिर से बनाता है, keyid द्वारा संदर्भित public key खोजता है, और signature जांचता है। यदि transit के दौरान signature द्वारा covered कोई भी चीज़ बदल गई हो, तो verification असफल हो जाती है।

Apps, APIs और MCP servers के लिए यह क्यों महत्वपूर्ण है

अधिकांश automated traffic अपनी पहचान user-agent string या स्वयं चुने गए client name से देता है। दोनों को आसानी से कॉपी किया जा सकता है। Message signature अलग है: यह request को किसी key से जोड़ती है, और केवल private key का धारक ही मान्य signature बना सकता है। Crawlers, assistants और autonomous agents से traffic प्राप्त करने वाले application के लिए, यह "यह client कहता है कि वह X है" को बदलकर "यह request X द्वारा प्रकाशित key से sign की गई थी" बना देता है।

यह अंतर सहयोग करने वाले automated clients को anonymous traffic के बजाय ज्ञात प्रतिभागियों की तरह मानने की नींव है। इससे API signed crawler को एक structured endpoint पर route कर सकता है, किसी known operator के लिए अलग rate limit लागू कर सकता है, या किसी MCP server को इस बारे में अधिक context दे सकता है कि tool किसने call किया।

व्यवहार में verification कैसे काम करती है

1. Signature-Input और Signature को parse करें और पुष्टि करें कि अपेक्षित components शामिल हैं। जो signature उपयोगी चीज़ों को cover नहीं करता, वह बहुत कम साबित करता है।
2. stale या replay किए गए requests को अपनी सहनशीलता के भीतर अस्वीकार करने के लिए created और expires parameters जांचें (signature replay पर Section 7.2.2 देखें)।
3. keyid को किसी public key में resolve करें, किसी ऐसे स्रोत से जिस पर आप भरोसा करते हैं, जैसे operator द्वारा किसी ज्ञात स्थान पर प्रकाशित key directory। IETF का Web Bot Auth protocol draft automated clients के लिए ऐसी directory परिभाषित करता है।
4. निर्दिष्ट तरीके से signature base को बिल्कुल उसी तरह फिर से बनाएं और घोषित algorithm से उसे verify करें।
5. क्या verified हुआ और किस context में, इसे record करें, ताकि बाद के निर्णय इसका संदर्भ ले सकें।

Production में, हाथ से लिखी parsing के बजाय maintained RFC 9421 implementation का उपयोग करें: canonicalization के विवरण में गलती करना आसान है। signed AI agent requests को verify करने का तरीका वाला guide code के साथ हर चरण समझाता है।

एक मान्य signature क्या साबित करती है और क्या नहीं

एक मान्य signature यह साबित करती है कि request किसी key से sign की गई थी, और यदि key किसी domain के अंतर्गत प्रकाशित है, तो request उस domain के operator से जुड़ी है। यह यह साबित नहीं करती:

• कि operator ईमानदार है या action सुरक्षित है,
• कि किसी person ने request को निर्देशित या अनुमोदित किया था (delegated authority देखें),
• कि client को वह करने की अनुमति है जो वह मांग रहा है (agent authorization देखें)।

Identity evidence और permission अलग प्रश्न हैं। आपके application की अपनी authentication और authorization अभी भी तय करती है कि कोई client क्या कर सकता है। signed AI agent requests क्या साबित करती हैं, और क्या नहीं पर हमारा blog post इसे और विस्तार से कवर करता है।

सामान्य गलतफहमियां

• "Signed means trusted." Signed का मतलब है जिम्मेदारी तय की जा सकती है। Trust उस attributed party के बारे में आपका policy decision है।
• "Signatures API keys की जगह ले लेती हैं." वे अलग प्रश्नों के जवाब देती हैं। API key बताती है कि कौन सा account call कर रहा है; signature बताती है कि किस client ने request बनाई। कई deployments दोनों से लाभ लेते हैं।
• "Unsigned traffic malicious है." आज का अधिकांश automated traffic unsigned है। Signature का न होना केवल यह कम करता है कि क्या स्थापित किया जा सकता है, इससे अधिक नहीं। इसी कारण Unknown एक first-class result है।

Proof of Actor signatures को कैसे संभालता है

Proof of Actor में, जो signature published key के विरुद्ध validate होती है, उसे basis verified के साथ दर्ज किया जाता है, और केवल उसी तक सीमित रखा जाता है जो check ने स्थापित किया: key और वह identifier जिससे वह संबंधित है। परिणामी class (आमतौर पर Agent) कभी authorization का संकेत नहीं देती। Results analysis के लिए Understand में और Route में जाते हैं, जहां आपकी अपनी policies तय करती हैं कि signed client को structured path मिलेगा, अलग limit मिलेगी, या कोई बदलाव नहीं होगा। Web Bot Auth जैसे signed-agent standards विकसित हो रहे हैं, और Proof of Actor को signed requests के mature होने पर उन्हें verify करने के लिए बनाया गया है।

क्या evidence स्थापित कर सकता है पर और पढ़ें, या early access के लिए apply करें.

स्रोत

• RFC 9421: HTTP Message Signatures: signature components, parameters और verification को परिभाषित करने वाला IETF standard
• RFC 9651: Structured Field Values for HTTP: Signature-Input और Signature की syntax
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft जो RFC 9421 को automated clients पर लागू करता है (November 2026 तक work in progress)