Web Bot Auth

Web Bot Auth എന്താണ്

Web Bot Auth എന്നത് ഒരു IETF working group-ന്റെ പേരും automated web traffic-നെ authenticate ചെയ്യുന്നതിനുള്ള അതിന്റെ Internet-Draft പ്രവർത്തനവുമാണ്. ആശയം നേരിട്ടുള്ളതാണ്: crawlers, AI assistants, autonomous agents എന്നിവർ അവരുടെ HTTP requests HTTP Message Signatures (RFC 9421) ഉപയോഗിച്ച് ഒപ്പിടുന്നു, കൂടാതെ ആ signatures verify ചെയ്യുന്ന public keys അവർ നിയന്ത്രിക്കുന്ന ഒരു identifier-ന്റെ കീഴിൽ publish ചെയ്യുന്നു. അപ്പോൾ ഒരു website-ന്, ആരും copy ചെയ്യാവുന്ന user-agent string-ിനെ ആശ്രയിക്കുന്നതിന് പകരം, ഒരു request യഥാർത്ഥത്തിൽ അത് പേര് പറയുന്ന operator-ൽ നിന്നാണോ വന്നത് എന്ന് സ്ഥിരീകരിക്കാനാകും. ഒരു product team-യ്ക്ക് ഇത് എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് അറിയാൻ Web Bot Auth for product teams കാണുക; implementation steps-ിനായി how to verify signed AI agent requests എന്ന guide കാണുക.

2026 നവംബർ വരെ, working group-ന്റെ 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 എന്നിവ നിർവചിക്കുന്നു. working group documents page ഇതിനെ ബന്ധപ്പെട്ട individual drafts-ിനൊപ്പം പട്ടികപ്പെടുത്തുന്നു. ഇവ Internet-Drafts ആകുന്നു, അതായത് ഇവ പുരോഗമനത്തിലുള്ള പ്രവർത്തനങ്ങളാണ്. keys എങ്ങനെ discover ചെയ്യപ്പെടുന്നു, request components-ൽ ഏവയെ sign ചെയ്യണം, operator information ഏത് headers-ൽ carry ചെയ്യണം തുടങ്ങിയ വിശദാംശങ്ങൾ പതിപ്പുകൾക്കിടയിൽ മാറാം. Implementers നിലവിലെ drafts പിന്തുടരണം, ഏതെങ്കിലും snapshot അല്ല.

ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

Websites ഉം APIs ഉം ദീർഘകാലമായി bots-നെ user-agent strings ഉം IP ranges ഉം ഉപയോഗിച്ചാണ് തിരിച്ചറിഞ്ഞിട്ടുള്ളത്. രണ്ടിനും പരിധികളുണ്ട്: user-agent strings വളരെ എളുപ്പത്തിൽ spoof ചെയ്യാം (കാണുക user-agent spoofing), കൂടാതെ IP ranges മാറിക്കൊണ്ടിരിക്കുകയും cloud providers-ക്കിടയിൽ പങ്കിടപ്പെടുകയും ചെയ്യുന്നു. AI agents ആളുകളുടെ പേരിൽ browse ചെയ്യാനും, APIs വിളിക്കാനും, MCP servers ഉപയോഗിക്കാനും തുടങ്ങുമ്പോൾ, applications-ക്ക് സഹകരിക്കുന്ന automated clients-നെ anonymous ones-ിൽ നിന്ന് വേർതിരിക്കാൻ കൂടുതൽ ശക്തമായ ഒരു മാർഗം ആവശ്യമാണ്.

Signed requests ആ കൂടുതൽ ഉറച്ച അടിത്തറ നൽകുന്നു. Verified signature ഒരു application-ന് known operator-നെ സ്ഥിരമായി തിരിച്ചറിയാനും, human-shaped interface-ിന് പകരം structured path നൽകാനും, അതിന്റെ activity കൃത്യമായി അളക്കാനും അനുവദിക്കുന്നു.

ഉയർന്ന തലത്തിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു

1. Operator ഒരു key pair generate ചെയ്യുകയും അതിന്റെ identity-യുമായി ബന്ധിപ്പിച്ച സ്ഥലത്ത് public key publish ചെയ്യുകയും ചെയ്യുന്നു, സാധാരണയായി അതിന്റെ 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 publish ചെയ്ത keys fetch ചെയ്യുകയോ cache ചെയ്യുകയോ ചെയ്യുന്നു, signature base പുനർനിർമ്മിച്ച് signature verify ചെയ്യുന്നു.
4. വിജയിച്ചാൽ, ആ request ആ published identifier-ുമായി ബന്ധപ്പെട്ട ആ key-ന്റെ holder നിർമ്മിച്ചതാണെന്ന് site-ന് അറിയാം.

ഇത് എന്താണ് സ്ഥാപിക്കുന്നത്, എന്തല്ല

ഒരു Web Bot Auth signature automated client-നെ authenticate ചെയ്യുന്നു. ഇത് താഴെക്കൊടുത്തിരിക്കുന്ന കാര്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നില്ല:

• operator അത് ആവശ്യപ്പെടുന്നതു ചെയ്യാൻ അനുവദിക്കപ്പെട്ടിട്ടുണ്ടോ (agent authorization),
• ഒരു person ആ action നിർദ്ദേശിച്ചോ അംഗീകരിച്ചോ ചെയ്തോ (delegated authority),
• ആ action സുരക്ഷിതമാണോ, അല്ലെങ്കിൽ തിരികെ ലഭിക്കുന്ന content യുക്തമായി ഉപയോഗിക്കപ്പെടുമോ.

അവ receiving application-ന്റെ സ്വന്തം authentication, authorization, policy എന്നിവയ്ക്കുള്ള തീരുമാനങ്ങളായി തുടരുന്നു. what signed AI agent requests prove, and what they don't എന്നതിനെക്കുറിച്ചുള്ള നമ്മുടെ blog post ഈ അതിരു അന്വേഷിക്കുന്നു.

പൊതുവായ തെറ്റിദ്ധാരണകൾ

• "എല്ലാ bot ഉം ഉടൻ sign ചെയ്യും." സ്വീകരണം client-by-client ആയി വളരുന്നു. Applications-ന് ദീർഘകാലം signed, declared, anonymous traffic എന്നിവയുടെ മിശ്രണം കാണാം, അതിനാൽ ഓരോന്നിനെയും കൈകാര്യം ചെയ്യാൻ വ്യക്തമായ മാർഗം ആവശ്യമാണ്.
• "ഒരു signature bot-നെ നല്ലതാക്കുന്നു." അത് bot-നെ known ആക്കുന്നു. Known എന്നത് policy-ക്കുള്ള തുടക്കമാണ്, policy തന്നെയല്ല.
• "Draft അന്തിമമാണ്." അത് വളരുന്ന Internet-Draft ആണ്. നിലവിലെ text-നുസരിച്ച് build ചെയ്യുക, revisions പ്രതീക്ഷിക്കുക.

Proof of Actor ഇതുമായി എങ്ങനെ ബന്ധപ്പെടുന്നു

Proof of Actor validated signature-നെ തെളിവായി, basis verified ആയി, അത് തെളിയിക്കുന്ന key-ക്കും identifier-ക്കും പരിധിയിട്ടു പരിഗണിക്കുന്നു. അത് declared names-ിൽ നിന്നും inferred signals-ിൽ നിന്നും അതിനെ വേർതിരിച്ചു നിർത്തുന്നു, കൂടാതെ identity-യെ permission ആയി ഒരിക്കലും മാറ്റുന്നില്ല. ഈ standards വികസിക്കുന്നതിനനുസരിച്ച് signed requests verify ചെയ്യുന്നതിനായാണ് Proof of Actor രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്; Route-ലുള്ള നിങ്ങളുടെ സ്വന്തം policies ഒരു verified agent എന്ത് ചെയ്യാം എന്ന് തീരുമാനിക്കുന്നു.

ഇത് APIs ഉം MCP servers ഉം എങ്ങനെ ചേരുന്നു എന്ന് കാണുക, അല്ലെങ്കിൽ apply for early access.

ഉറവിടങ്ങൾ

• IETF Web Bot Auth working group: charter, chairs and status
• Web Bot Auth working group documents: current working group and related drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory ഉം അതിന്റെ well-known URI ഉം (2026 നവംബർ വരെ work in progress)
• RFC 9421: HTTP Message Signatures: Web Bot Auth അടിസ്ഥാനമാക്കുന്ന signature standard