Web Bot Auth

Web Bot Auth क्या है

Web Bot Auth एक IETF working group और उसके Internet-Draft कार्य का नाम है, जो automated web traffic को authenticate करने से संबंधित है। विचार सीधा है: crawlers, AI assistants और autonomous agents अपने HTTP अनुरोधों पर HTTP Message Signatures (RFC 9421) का उपयोग करके sign करते हैं, और उन signatures को verify करने वाली public keys को एक ऐसे identifier के तहत प्रकाशित करते हैं जिसे वे नियंत्रित करते हैं। फिर कोई website यह पुष्टि कर सकती है कि कोई अनुरोध वास्तव में उसी operator से आया है जिसका नाम दिया गया है, बजाय इसके कि वह ऐसे user-agent string पर निर्भर हो जिसे कोई भी copy कर सकता है। इसका product team के लिए क्या अर्थ है, यह देखने के लिए Web Bot Auth for product teams देखें; implementation steps के लिए signed AI agent requests को verify करने का तरीका वाला guide देखें।

November 2026 तक, working group का core document draft-ietf-webbotauth-httpsig-protocol है, जो in-band key discovery के लिए एक Signature-Agent header, JSON Web Key Sets पर आधारित key directory format, और एक well-known URI परिभाषित करता है जहाँ वह directory serve की जाती है। working group documents page इसे संबंधित individual drafts के साथ सूचीबद्ध करती है। ये Internet-Drafts हैं, यानी ये work in progress हैं। keys कैसे discover की जाती हैं, request के कौन-से components sign होने चाहिए, और कौन-से headers operator information carry करते हैं, जैसे विवरण versions के बीच बदल सकते हैं। Implementers को किसी भी snapshot के बजाय current drafts का पालन करना चाहिए।

इसका महत्व क्यों है

Websites और APIs लंबे समय से bots को user-agent strings और IP ranges के आधार पर पहचानते आए हैं। दोनों की सीमाएँ हैं: user-agent strings आसानी से spoof की जा सकती हैं (user-agent spoofing देखें), और IP ranges बदलती रहती हैं तथा cloud providers के बीच साझा होती हैं। जैसे-जैसे AI agents लोगों की ओर से browse करने, APIs call करने और MCP servers का उपयोग करने लगते हैं, applications को सहयोगी automated clients और anonymous clients के बीच अंतर करने का अधिक मजबूत तरीका चाहिए।

Signed requests वह अधिक मजबूत आधार देते हैं। एक verified signature application को किसी known operator को consistently पहचानने, मानव-जैसे interface के बजाय उसे एक structured path देने, और उसकी activity को सटीक रूप से मापने में सक्षम बनाता है।

उच्च स्तर पर यह कैसे काम करता है

1. Operator एक key pair बनाता है और public key को अपनी identity से जुड़ी किसी location पर प्रकाशित करता है, आम तौर पर अपने domain के नीचे http-message-signatures-directory well-known path पर।
2. हर request में चुने गए request components को कवर करने वाले Signature-Input और Signature headers शामिल होते हैं, साथ ही एक key identifier और key directory की ओर संकेत करने वाला Signature-Agent header भी होता है।
3. प्राप्त करने वाली site operator की प्रकाशित keys को fetch या cache करती है, signature base को फिर से बनाती है और signature verify करती है।
4. सफल होने पर site जानती है कि request उस key के holder द्वारा बनाई गई थी, जो उस प्रकाशित identifier से संबद्ध है।

यह क्या स्थापित करता है, और क्या नहीं

Web Bot Auth signature automated client को authenticate करता है। यह इन प्रश्नों का उत्तर नहीं देता:

• क्या operator को वही करने की अनुमति है जो वह मांग रहा है (agent authorization),
• क्या किसी व्यक्ति ने उस action को निर्देशित या approved किया (delegated authority),
• क्या action सुरक्षित है या लौटाई गई सामग्री का उपयोग उचित रूप से किया जाएगा।

ये निर्णय प्राप्त करने वाले application की अपनी authentication, authorization और policy के लिए बने रहते हैं। हमारा blog post signed AI agent requests क्या साबित करते हैं, और क्या नहीं इस सीमा को विस्तार से देखता है।

आम गलत धारणाएँ

• "हर bot जल्द ही sign करेगा." Adoption client दर client बढ़ती है। लंबे समय तक applications को signed, declared और anonymous traffic का मिश्रण दिखेगा, इसलिए उन्हें हर एक को संभालने का स्पष्ट तरीका चाहिए।
• "Signature bot को अच्छा बना देती है." यह bot को known बनाती है। Known किसी policy की शुरुआत है, policy स्वयं नहीं।
• "Draft final है." यह एक evolving Internet-Draft है। Current text के अनुसार build करें और revisions की अपेक्षा रखें।

Proof of Actor का इससे क्या संबंध है

Proof of Actor एक validated signature को basis verified वाली evidence के रूप में मानता है, उसी key और identifier के दायरे में जिसे वह साबित करता है। यह उसे declared names और inferred signals से अलग रखता है, और identity को permission में कभी नहीं बदलता। Proof of Actor को इन standards के mature होने के साथ signed requests verify करने के लिए डिज़ाइन किया गया है; Route में आपकी अपनी policies तय करती हैं कि कोई verified agent क्या कर सकता है।

देखें कि यह APIs और MCP servers में कैसे फिट होता है, या early access के लिए आवेदन करें।

स्रोत

• IETF Web Bot Auth working group: charter, chairs और status
• Web Bot Auth working group documents: current working group और संबंधित drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory और उसका well-known URI (November 2026 तक work in progress)
• RFC 9421: HTTP Message Signatures: signature standard जिस पर Web Bot Auth आधारित है