Web Bot Auth

Web Bot Auth কি

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

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

ইয়াৰ প্ৰাসংগিকতা কিয় আছে

Website আৰু API-এ বহুদিন ধৰি user-agent string আৰু IP range ব্যৱহাৰ কৰি bot চিনাক্ত কৰি আহিছে। দুয়োটাৰে সীমাবদ্ধতা আছে: user-agent string সহজে spoof কৰিব পাৰি (user-agent spoofing চাওক), আৰু IP range-সমূহ সলনি হয় আৰু cloud provider-সমূহৰ মাজত ভাগ হ'ব পাৰে। AI agent-এ যেতিয়া মানুহৰ হৈ browser ব্যৱহাৰ কৰা, API call কৰা আৰু MCP servers ব্যৱহাৰ কৰা আৰম্ভ কৰে, তেতিয়া application-সমূহক সহযোগী স্বয়ংক্ৰিয় client আৰু বেনামী client-ৰ মাজত পাৰ্থক্য কৰিবলৈ অধিক দৃঢ় উপায়ৰ প্ৰয়োজন হয়।

স্বাক্ষৰিত অনুৰোধে সেই অধিক দৃঢ় ভিত্তি দিয়ে। যাচাইকৃত signature-এ application-এ এটা চিনাকি operator-কে স্থিৰভাৱে চিনিব পাৰে, human-shaped interface-ৰ সলনি এটা গঠিত পথ দিব পাৰে, আৰু তাৰ কাৰ্যকলাপ সঠিকভাৱে measure কৰিব পাৰে।

উচ্চ স্তৰত ই কেনেদৰে কাম কৰে

1. Operator-এ এটা key pair সৃষ্টি কৰে আৰু তাৰ public key-টো তাৰ identity-ৰ সৈতে সংযুক্ত এটা স্থানত প্ৰকাশ কৰে, সাধাৰণতে তাৰ domain-ৰ অধীনত থকা http-message-signatures-directory well-known path-ত।
2. প্ৰতিটো অনুৰোধত নিৰ্বাচিত request component-সমূহ সামৰি Signature-Input আৰু Signature header থাকে, লগতে এটা key identifier থাকে, আৰু key directory-লৈ সূচোৱা এটা Signature-Agent header থাকে।
3. অনুৰোধ গ্ৰহণ কৰা 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-টো safe নে নাই, বা ঘূৰাই দিয়া content-টো উপযুক্তভাৱে ব্যৱহাৰ কৰা হ'ব নে নহয়।

এইবোৰ গ্রহণ কৰা application-ৰ নিজৰ authentication, authorization আৰু policy-ৰ সিদ্ধান্ত হৈয়ে থাকে। আমাৰ signed AI agent requests-এ কি প্ৰমাণ কৰে, আৰু কি নকৰে শীৰ্ষক blog post-এ এই সীমা অন্বেষণ কৰে।

সাধাৰণ ভুল ধাৰণা

• "সকলো bot অতি শীঘ্ৰেই স্বাক্ষৰ কৰিব।" গ্ৰহণ client-ৰ পৰা client-লৈ বৃদ্ধি পায়। Application-এ বহু দিনলৈ signed, declared আৰু anonymous traffic-ৰ মিশ্ৰণ দেখিব, সেয়েহে প্ৰতিটোকে সামলাবলৈ স্পষ্ট উপায়ৰ প্ৰয়োজন আছে।
• "Signature থাকিলে bot ভাল হৈ যায়।" ই bot-টোক চিনাকি কৰি তোলে। চিনাকি হোৱা হৈছে policy-ৰ আৰম্ভণি, policy নিজেই নহয়।
• "Draft-টো চূড়ান্ত।" ই এটা বিকাশমান Internet-Draft। বৰ্তমান পাঠৰ ভিত্তিত কাম কৰক আৰু সংশোধনৰ আশা ৰাখক।

Proof of Actor-ৰ সৈতে ইয়াৰ সম্পৰ্ক

Proof of Actor-এ validate কৰা signature-টোক basis verified থকা evidence হিচাপে গণ্য কৰে, আৰু ইয়াক যি key আৰু identifier-এ প্ৰমাণ কৰে, সেই পৰিসীমাৰ ভিতৰত ৰাখে। ই সেইটো declared নাম আৰু inferred signal-ৰ পৰা পৃথককৈ ৰাখে, আৰু identity-টোক কেতিয়াও permission-লৈ ৰূপান্তৰ নকৰে। Standards পৰিপক্ক হোৱাৰ লগে লগে signed অনুৰোধ verify কৰাৰ বাবে Proof of Actor ডিজাইন কৰা হৈছে; 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 অনুসৰি কাম চলি আছে)
• RFC 9421: HTTP Message Signatures: Web Bot Auth-এ আধাৰ হিচাপে ব্যৱহাৰ কৰা signature standard