HTTP Message Signatures (RFC 9421)

HTTP Message Signatures म्हणजे काय

HTTP Message Signatures RFC 9421 मध्ये परिभाषित आहेत, जो HTTP request किंवा response च्या काही भागांवर डिजिटल signature तयार आणि verify करण्यासाठीचा IETF standard आहे. क्लायंट कोणते घटक कव्हर करायचे ते निवडतो (उदाहरणार्थ method, target URI, authority आणि निवडलेले headers), त्यांपासून canonical signature base तयार करतो, आणि private key ने त्यावर स्वाक्षरी करतो. परिणाम दोन headers मध्ये जातो: Signature-Input (Section 4.1), ज्यात कव्हर केलेले घटक आणि created, expires, keyid आणि alg यांसारखी parameters सूचीबद्ध असतात, आणि Signature (Section 4.2), ज्यात signature value स्वतः असते. दोन्ही RFC 9651 ची Structured Field Values syntax वापरतात.

Receiver स्वतःला प्रत्यक्ष मिळालेल्या request मधून तोच signature base (Section 2.5) पुन्हा तयार करतो, keyid मध्ये संदर्भित सार्वजनिक key शोधतो, आणि signature तपासतो. signature ने कव्हर केलेल्या कोणत्याही गोष्टीत transit दरम्यान बदल झाला असेल, तर verification अयशस्वी होते.

Apps, APIs आणि MCP servers साठी त्यांचे महत्त्व का आहे

बहुतेक automated traffic user-agent string किंवा client ने स्वतः निवडलेल्या नावाने स्वतःची ओळख करून देतो. दोन्ही सहजपणे कॉपी करता येतात. Message signature वेगळी आहे: ती request ला key शी जोडते, आणि केवळ private key चा धारकच वैध signature तयार करू शकतो. Crawlers, assistants आणि autonomous agents कडून traffic स्वीकारणाऱ्या application साठी, याचा अर्थ "हा client सांगतो की तो X आहे" याऐवजी "ही request X प्रकाशित करत असलेल्या key ने sign केली आहे" असा होतो.

हा फरक सहकार्य करणाऱ्या automated clients ना anonymous traffic ऐवजी ज्ञात participants म्हणून हाताळण्याचा पाया आहे. यामुळे API signed crawler ला structured endpoint कडे route करू शकतो, ज्ञात operator साठी वेगळे rate limit लागू करू शकतो, किंवा MCP server ला tool कॉल करणारा कोण आहे याबद्दल अधिक context देऊ शकतो.

प्रत्यक्षात verification कसे काम करते

1. Signature-Input आणि Signature parse करा आणि अपेक्षित components कव्हर झाले आहेत याची खात्री करा. काहीही उपयुक्त न कव्हर करणारी signature फारसे सिद्ध करत नाही.
2. तुमच्या tolerance मध्ये stale किंवा replayed request नाकारण्यासाठी created आणि expires parameters तपासा (signature replay बद्दल Section 7.2.2 पहा).
3. keyid ला तुमचा विश्वास असलेल्या source मधील public key शी resolve करा, जसे operator ने ज्ञात ठिकाणी प्रकाशित केलेली key directory. automated clients साठी अशी directory IETF Web Bot Auth protocol draft मध्ये परिभाषित आहे.
4. specified प्रमाणे signature base अचूकपणे पुन्हा तयार करा आणि declared algorithm ने ती verify करा.
5. काय verified झाले आणि कोणत्या context मध्ये, ते नोंदवा, जेणेकरून नंतरचे निर्णय त्याचा संदर्भ घेऊ शकतील.

Production मध्ये hand-rolled parsing ऐवजी maintained RFC 9421 implementation वापरा: canonicalization मधील तपशील चुकणे सोपे असते. signed AI agent requests कसे verify करायचे या guide मध्ये code सह प्रत्येक टप्पा समजावला आहे.

वैध signature काय सिद्ध करते आणि काय सिद्ध करत नाही

वैध signature हे सिद्ध करते की request एका key ने sign केली होती, आणि key जर domain अंतर्गत published असेल, तर request त्या domain च्या operator शी संबंधित आहे. हे पुढील गोष्टी सिद्ध करत नाही:

• operator प्रामाणिक आहे किंवा action सुरक्षित आहे,
• एखाद्या व्यक्तीने request सूचित केली किंवा मंजूर केली होती का (पहा delegated authority),
• client ला जे करायचे आहे ते करण्याची परवानगी आहे का (पहा agent authorization).

Identity evidence आणि permission या वेगळ्या गोष्टी आहेत. तुमच्या application चे स्वतःचे authentication आणि authorization अजूनही client काय करू शकतो ते ठरवतात. signed AI agent requests काय सिद्ध करतात आणि काय नाही या आमच्या blog post मध्ये याचे अधिक तपशील आहेत.

सामान्य गैरसमज

• "Signed म्हणजे trusted." Signed म्हणजे attributable. Trust हा तुम्ही attributed party बद्दल घेतलेला policy निर्णय आहे.
• "Signatures API keys ची जागा घेतात." त्या वेगळ्या प्रश्नाचे उत्तर देतात. API key कोणते account कॉल करत आहे हे सांगते; signature कोणत्या client ने request तयार केली हे सांगते. अनेक deployments मध्ये दोन्ही उपयुक्त ठरतात.
• "Unsigned traffic malicious असतो." आज बहुतेक automated traffic unsigned असतो. Signatures नसल्याने काय स्थापित करता येईल ते कमी होते, यापेक्षा अधिक नाही. म्हणूनच Unknown हा first-class result आहे.

Proof of Actor signatures कसे हाताळते

Proof of Actor मध्ये प्रकाशित key विरुद्ध validate होणारी signature verified basis सह नोंदवली जाते, आणि check ने नेमके काय स्थापित केले आहे त्यापुरती मर्यादित असते: key आणि ती ज्या identifier शी संबंधित आहे तो. resulting class (साधारणपणे Agent) कधीही authorization सूचित करत नाही. Results analysis साठी Understand मध्ये आणि Route मध्ये प्रवाहित होतात, जिथे तुमची स्वतःची policies ठरवतात की signed client ला structured path मिळेल, वेगळा limit मिळेल, की कोणताही बदल होणार नाही. Web Bot Auth सारखे signed-agent standards विकसित होत आहेत, आणि Proof of Actor तयार केले आहे की हे standards परिपक्व होत असताना signed requests verify करता याव्यात.

what the evidence can establish याबद्दल अधिक वाचा, किंवा apply for early access.

Sources

• 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: automated clients वर RFC 9421 लागू करणारा IETF Web Bot Auth draft (November 2026 पर्यंत work in progress)