Web Bot Auth

Web Bot Auth কী

Web Bot Auth হল একটি IETF working group-এর নাম এবং স্বয়ংক্রিয় web traffic প্রমাণীকরণের জন্য এর Internet-Draft কাজ। ধারণাটি সরল: crawler, AI assistant এবং autonomous agent-রা HTTP Message Signatures (RFC 9421) ব্যবহার করে তাদের HTTP অনুরোধে স্বাক্ষর করে, এবং যে identifier তারা নিয়ন্ত্রণ করে তার অধীনে সেই signature যাচাই করার জন্য public key প্রকাশ করে। এরপর একটি website নিশ্চিত করতে পারে যে একটি অনুরোধ সত্যিই সেই operator-এর কাছ থেকেই এসেছে, যার নাম সেখানে উল্লেখ আছে, instead of এমন একটি user-agent string-এর ওপর নির্ভর করা যা যে কেউ কপি করতে পারে। একটি product team-এর জন্য এর অর্থ কী, তা জানতে দেখুন Web Bot Auth for product teams; implementation ধাপের জন্য দেখুন signed AI agent request কীভাবে verify করতে হয় গাইডটি।

November 2026 পর্যন্ত, working group-এর মূল document হল draft-ietf-webbotauth-httpsig-protocol, যা in-band key discovery-এর জন্য একটি Signature-Agent header, JSON Web Key Sets-ভিত্তিক একটি key directory format এবং সেই directory পরিবেশনের জন্য একটি well-known URI নির্ধারণ করে। working group documents page-এ এটি সংশ্লিষ্ট individual draft-গুলোর পাশে তালিকাভুক্ত আছে। এগুলো Internet-Draft, অর্থাৎ এগুলো চলমান কাজ। কীভাবে key discover করা হবে, অনুরোধের কোন কোন component-এ স্বাক্ষর করতে হবে, এবং operator তথ্য কোন header বহন করবে - এসব বিবরণ সংস্করণভেদে বদলাতে পারে। Implementer-দের উচিত বর্তমান draft-গুলো অনুসরণ করা, কোনো snapshot নয়।

কেন এটি গুরুত্বপূর্ণ

Website এবং API অনেক দিন ধরে user-agent string এবং IP range দিয়ে bot শনাক্ত করে এসেছে। দুটিরই সীমাবদ্ধতা আছে: user-agent string সহজেই জাল করা যায় (user-agent spoofing দেখুন), আর IP range পরিবর্তিত হয় এবং cloud provider-দের মধ্যে ভাগাভাগি হয়ে যায়। AI agent যখন মানুষের পক্ষে web ব্রাউজ করতে, API কল করতে এবং MCP servers ব্যবহার করতে শুরু করছে, তখন application-গুলোর একটি বেশি মজবুত উপায় দরকার, যাতে সহযোগী স্বয়ংক্রিয় client-কে anonymous client থেকে আলাদা করা যায়।

স্বাক্ষরিত অনুরোধ সেই বেশি মজবুত ভিত্তি দেয়। একটি verified signature application-কে একটি পরিচিত operator-কে ধারাবাহিকভাবে চিনতে, human-shaped interface-এর বদলে একটি structured path দিতে এবং তার activity নির্ভুলভাবে মাপতে সাহায্য করে।

উচ্চ পর্যায়ে এটি কীভাবে কাজ করে

1. Operator একটি key pair তৈরি করে এবং তার identity-র সঙ্গে যুক্ত একটি স্থানে public key প্রকাশ করে, সাধারণত তার domain-এর অধীনে http-message-signatures-directory well-known path-এ।
2. প্রতিটি অনুরোধে Signature-Input এবং Signature header থাকে, যাতে নির্বাচিত request component-গুলো অন্তর্ভুক্ত থাকে, সঙ্গে একটি key identifier, এবং key directory-এর দিকে নির্দেশ করা একটি Signature-Agent header।
3. Receiving site operator-এর প্রকাশিত key fetch বা cache করে, signature base পুনর্গঠন করে এবং signature verify করে।
4. সফল হলে, site জানে যে অনুরোধটি ওই key-এর holder-এর দ্বারা তৈরি, যা সেই প্রকাশিত identifier-এর সঙ্গে যুক্ত।

এটি কী প্রতিষ্ঠা করে, আর কী করে না

একটি Web Bot Auth signature স্বয়ংক্রিয় client-কে authenticate করে। এটি এই প্রশ্নগুলোর উত্তর দেয় না:

• operator যা চাইছে তা করার অনুমতি তার আছে কি না (agent authorization),
• কোনো ব্যক্তি action-টি নির্দেশ বা অনুমোদন করেছে কি না (delegated authority),
• action-টি নিরাপদ কি না বা ফেরত আসা content যথাযথভাবে ব্যবহার করা হবে কি না।

এসব সিদ্ধান্ত থেকে যায় receiving application-এর নিজের authentication, authorization এবং policy-এর ওপর। আমাদের blog post signed AI agent request কী প্রমাণ করে, আর কী করে না এই সীমারেখা বিশ্লেষণ করে।

সাধারণ ভুল ধারণা

• "প্রতিটি bot শিগগিরই স্বাক্ষর করবে।" গ্রহণযোগ্যতা client থেকে client-এ বাড়ে। application দীর্ঘ সময় ধরে signed, declared এবং anonymous traffic-এর মিশ্রণ দেখবে, তাই প্রতিটিকে সামলানোর একটি পরিষ্কার উপায় দরকার।
• "একটি signature bot-কে ভালো বানায়।" এটি bot-কে পরিচিত করে। পরিচিত হওয়া policy-এর সূচনা, policy নিজে নয়।
• "draft চূড়ান্ত।" এটি একটি evolving Internet-Draft। বর্তমান text অনুযায়ী তৈরি করুন এবং revision আশা করুন।

Proof of Actor-এর সঙ্গে এর সম্পর্ক

Proof of Actor একটি validated signature-কে verified basis-এর evidence হিসেবে বিবেচনা করে, যা এটি প্রমাণ করে সেই key এবং identifier-এর সীমার মধ্যে। এটি declared name এবং inferred signal থেকে সেটি আলাদা রাখে, এবং identity-কে কখনও permission-এ রূপান্তর করে না। Proof of Actor তৈরি করা হয়েছে এই standards পরিণত হওয়ার সঙ্গে সঙ্গে signed অনুরোধ verify করার জন্য; Route-এ আপনার নিজস্ব policy নির্ধারণ করবে একটি verified agent কী করতে পারবে।

দেখুন এটি কীভাবে APIs এবং MCP servers-এর মধ্যে কাজ করে, অথবা early access-এর জন্য আবেদন করুন।

উৎস

• IETF Web Bot Auth working group: charter, chairs এবং status
• Web Bot Auth working group documents: বর্তমান working group এবং সংশ্লিষ্ট draft
• 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 নির্মিত