Web Bot Auth

Web Bot Auth म्हणजे काय

Web Bot Auth हे IETF working group आणि authenticated automated web traffic साठीच्या त्याच्या Internet-Draft कामाचे नाव आहे. कल्पना सोपी आहे: crawlers, AI assistants आणि autonomous agents त्यांच्या HTTP requests वर HTTP Message Signatures (RFC 9421) वापरून स्वाक्षरी करतात, आणि त्या स्वाक्षऱ्या पडताळणाऱ्या public keys ते ज्या identifier वर नियंत्रण ठेवतात त्याखाली प्रकाशित करतात. त्यानंतर website हे पुष्टी करू शकते की request खरंच त्याने named केलेल्या operator कडून आली आहे, user-agent string वर अवलंबून राहण्याऐवजी, जी कोणीही copy करू शकतो. याचा product team साठी काय अर्थ आहे ते पाहण्यासाठी product teams साठी Web Bot Auth पहा; implementation steps साठी signed AI agent requests कसे verify करायचे हा guide पहा.

November 2026 पर्यंत, working group's core document draft-ietf-webbotauth-httpsig-protocol आहे, जो in-band key discovery साठी Signature-Agent header, JSON Web Key Sets वर आधारित key directory format, आणि त्या directory साठी serve होणारा well-known URI define करतो. working group documents page तो संबंधित individual drafts सोबत सूचीबद्ध करते. हे Internet-Drafts आहेत, म्हणजेच ते work in progress आहेत. keys कशा शोधल्या जातात, request चे कोणते components sign करणे आवश्यक आहे, आणि operator information कोणते headers carry करतात यासारखे तपशील versions दरम्यान बदलू शकतात. Implementers ने कोणत्याही snapshot ऐवजी current drafts चे पालन करावे.

त्याचे महत्त्व काय

वेबसाइट्स आणि APIs दीर्घकाळ bot ओळखण्यासाठी user-agent strings आणि IP ranges वापरत आले आहेत. दोन्हींच्या मर्यादा आहेत: user-agent strings सहज spoof केल्या जाऊ शकतात (user-agent spoofing पहा), आणि IP ranges बदलतात तसेच cloud providers मध्ये shared असतात. AI agents जेव्हा लोकांच्या वतीने browse करायला, APIs call करायला आणि MCP servers वापरायला सुरुवात करतात, तेव्हा applications ना cooperating automated clients आणि anonymous ones यांच्यात फरक ओळखण्यासाठी अधिक मजबूत मार्गाची गरज असते.

Signed requests हा अधिक मजबूत आधार देतात. Verified signature application ला known operator ओळखण्यास सातत्याने मदत करते, human-shaped interface ऐवजी त्याला structured path देते, आणि त्याची activity अचूकपणे मोजू देते.

उच्च पातळीवर ते कसे कार्य करते

1. Operator एक key pair तयार करतो आणि public key त्याच्या identity शी जोडलेल्या ठिकाणी प्रकाशित करतो, सामान्यतः त्याच्या domain अंतर्गत असलेल्या http-message-signatures-directory well-known path वर.
2. प्रत्येक request मध्ये निवडलेल्या request components ना cover करणारे Signature-Input आणि Signature headers, plus एक key identifier, आणि key directory कडे निर्देश करणारा Signature-Agent header समाविष्ट असतो.
3. Receiving site operator चे प्रकाशित keys fetch किंवा cache करते, signature base पुन्हा तयार करते आणि signature verify करते.
4. यशस्वी झाल्यावर, site ला माहीत होते की request त्या key च्या holder ने तयार केली होती, जो त्या published identifier शी संबंधित आहे.

ते काय स्थापित करते, आणि काय करत नाही

Web Bot Auth signature automated client चे authentication करते. ते खालील प्रश्नांची उत्तरे देत नाही:

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

या सर्व गोष्टी receiving application's स्वतःच्या authentication, authorization आणि policy चे निर्णय राहतात. signed AI agent requests काय सिद्ध करतात, आणि काय नाही यावर आमचा blog post ही मर्यादा स्पष्ट करतो.

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

• "लवकरच प्रत्येक bot sign करेल." स्वीकार client नुसार वाढतो. Applications ना बराच काळ signed, declared आणि anonymous traffic यांचे मिश्रण दिसेल, म्हणून प्रत्येकाला हाताळण्यासाठी स्पष्ट मार्ग आवश्यक आहे.
• "Signature मुळे bot चांगला ठरतो." ती bot ला known करते. Known असणे हे policy साठी सुरुवातीचे बिंदू आहे, policy स्वतः नाही.
• "Draft अंतिम आहे." तो evolving Internet-Draft आहे. Current text वर आधारित काम करा आणि सुधारणा अपेक्षित ठेवा.

Proof of Actor याच्याशी त्याचा संबंध

Proof of Actor validated signature ला basis verified असलेला evidence मानतो, जो त्याने सिद्ध केलेल्या key आणि identifier पुरता scoped असतो. ते declared names आणि inferred signals पासून वेगळे ठेवले जाते, आणि identity कधीही permission मध्ये बदलली जात नाही. मानके परिपक्व होत असताना signed requests verify करण्यासाठी Proof of Actor डिझाइन केले आहे; Route मधील तुमची स्वतःची policies ठरवतात की verified agent काय करू शकतो.

हे APIs आणि MCP servers मध्ये कसे बसते ते पाहा, किंवा early access साठी apply करा.

स्रोत

• IETF Web Bot Auth working group: charter, chairs आणि status
• Web Bot Auth working group documents: current working group आणि related drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory आणि त्याचा well-known URI (November 2026 पर्यंत work in progress)
• RFC 9421: HTTP Message Signatures: Web Bot Auth ज्या signature standard वर आधारित आहे तो