പ്രധാന ഉള്ളടക്കത്തിലേക്ക് കടക്കുക
വിശദീകരണം

ഉൽപ്പന്ന ടീമുകൾക്കായി Web Bot Auth: signed agent requests നിങ്ങളുടെ roadmap-ന് എന്താണ് അർത്ഥമാക്കുന്നത്

AI agents ഉം crawlers ഉം User-Agent string മാത്രം ആശ്രയിക്കാതെ ആരാണെന്ന് തെളിയിക്കുന്ന ഒരു മാർഗം increasingly ആവശ്യപ്പെടുന്നു, കാരണം അത് ആരും copy ചെയ്യാം. IETF Web Bot Auth work അതിനെ standardize ചെയ്യാനുള്ള leading effort ആണ്. ഇത് product managers, engineering leads എന്നിവർക്കുള്ള ഒരു plain explanation ആണ്: ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, എന്താണ് ഇത് തെളിയിക്കുന്നത്, November 2026-ലെ അവസ്ഥ എന്താണ്, അതിനായി എങ്ങനെ plan ചെയ്യാം.

Early Access നേടുകഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് പര്യവേക്ഷണം ചെയ്യുക
Toshendra Sharma

രചിച്ചത് Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

വർഷങ്ങളായി, ഒരു automated client ഒരു website-നെ അത് ആരാണെന്ന് അറിയിക്കാൻ കഴിയുന്ന ഏക മാർഗം User-Agent header-യിലെ പേരും, ചില വലിയ operators-നായി മാത്രം, published IP addresses-ന്റെ list അല്ലെങ്കിൽ reverse DNS check ആണെന്നു മാത്രം ആയിരുന്നു. Names copy ചെയ്യാൻ എളുപ്പമാണ്. Network lists അവ maintain ചെയ്യുന്ന operators-നെ മാത്രമേ cover ചെയ്യൂ. AI agents web-ൽ യഥാർത്ഥ ആളുകൾക്കായി പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ, ആ gap ഒരു security issue മാത്രമല്ല, ഒരു product problem കൂടിയാണ്.

Web Bot Auth അതിനെ അടയ്ക്കാനുള്ള leading effort ആണ്. ഇത് automated clients-ന് അവരുടെ control-ലുള്ള, publish ചെയ്ത key ഉപയോഗിച്ച് അവരുടെ requests sign ചെയ്യാനുള്ള വഴി നൽകുന്നു, അതുവഴി ഒരു site ഒരു name-നെ trust ചെയ്യുന്നതിനുപകരം signature പരിശോധിക്കാം. ഇത് എന്താണെന്ന്, എന്താണ് മാറ്റുന്നത്, എന്തല്ല മാറ്റുന്നത് എന്നിവ specification-കൾ അവസാനം വരെ വായിക്കാതെ മനസ്സിലാക്കേണ്ട product managers, engineering leads എന്നിവർക്കുള്ളതാണ് ഈ explainer.

ചുരുക്കത്തിൽ

  • എന്താണ് ഇത്: automated HTTP clients-നെ authenticate ചെയ്യുന്നതിനായി IETF working group, webbotauth, അത് standardize ചെയ്യുന്ന സമീപനം.
  • ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു: client ഓരോ request-ലെയും ചില ഭാഗങ്ങൾ HTTP Message Signatures (RFC 9421) ഉപയോഗിച്ച് sign ചെയ്യുകയും, സ്വന്തം public keys-ന്റെ ഒരു directory-യിലേക്കാണ് pointer നൽകുകയും ചെയ്യുന്നു. Site key fetch ചെയ്ത് signature verify ചെയ്യുന്നു.
  • ഇത് എന്താണ് തെളിയിക്കുന്നത്: request sign ചെയ്ത key ഏതാണ് എന്നും, transit-ൽ signed parts മാറ്റം വന്നില്ല എന്നുമാണ്.
  • ഇത് എന്തല്ല തെളിയിക്കുന്നത്: agent അത് ചോദിക്കുന്നതു ചെയ്യാൻ authorized ആണോ, അത് ഒരു particular user-നുവേണ്ടി പ്രവർത്തിക്കുന്നുവോ, അല്ലെങ്കിൽ അത് നല്ല രീതിയിൽ പെരുമാറുമോ എന്നല്ല.
  • November 2026-ലെ നില: RFC 9421 published Proposed Standard ആണ്. Web Bot Auth protocol document ഇപ്പോഴും working group Internet-Draft ആണ്, RFC അല്ല.
  • എന്തുചെയ്യണം: valid signatures-നെ strong evidence ആയി treat ചെയ്യാൻ plan ചെയ്യുക, unsigned traffic കൈകാര്യം ചെയ്യുന്നത് തുടരുക, authorization തീരുമാനങ്ങൾ നിങ്ങളുടെ സ്വന്തം code-ൽ തന്നെ വയ്ക്കുക.

IETF Web Bot Auth work എന്താണ്

ക്രിപ്‌റ്റോഗ്രാഫിക്കായി automated clients-നെ authenticate ചെയ്യുന്നതിനും അവയുടെ പിന്നിലെ operators സംബന്ധിച്ച കൂടുതൽ വിവരം websites-ക്ക് നൽകുന്നതിനും വേണ്ട methods standardize ചെയ്യാൻ IETF Web Bot Auth working group charter ചെയ്തു. Charter പ്രധാനമായും ആളുകൾക്ക് സേവനം നൽകുന്ന sites-നെയാണ് ലക്ഷ്യമിടുന്നത്, കൂടാതെ scope-ൽ broad set of clients-നെ വ്യക്തമാക്കുന്നു: crawlers, web archivers, link checkers, AI training crawlers, end users-ക്കായി പ്രവർത്തിക്കുന്ന AI agents എന്നിവ.

Charter-ൽ ഉള്ള രണ്ട് exclusions product teams ശ്രദ്ധിക്കേണ്ടവയാണ്. End-user authentication scope-ൽ ഇല്ല, അതിനാൽ ഇത് ഒരു person-നെ login ചെയ്യാനുള്ള മാർഗമല്ല. Bot reputation tracking-ഉം scope-ൽ ഇല്ല, അതിനാൽ standard request sign ചെയ്തത് ആരാണെന്ന് പറയുന്നു, ആ operator വിശ്വസനീയനാണോ എന്ന് അല്ല.

Charter മൂന്ന് തരത്തിലുള്ള deliverables പട്ടികപ്പെടുത്തുന്നു:

  1. ആളുകൾക്കായി നിർമ്മിച്ച websites-ലേക്കുള്ള automated clients-നെ authenticate ചെയ്യാനുള്ള techniques സംബന്ധിച്ച Standards track documents.
  2. domain name അല്ലെങ്കിൽ URL പോലുള്ള existing identifier ഉപയോഗിച്ച് ഒരു requesting bot സംബന്ധിച്ച കൂടുതൽ വിവരങ്ങൾ convey ചെയ്യാനുള്ള Standards track documents.
  3. key management, lifecycle, deployment പോലുള്ള operational വിഷയങ്ങളിൽ Best current practice അല്ലെങ്കിൽ informational documents.

Documents-ന്റെ നിലവിലെ നില, November 2026-ലെ അവസ്ഥയിൽ

November 2026-നനുസരിച്ച്, working group-ക്ക് ഒരു adopted working group document മാത്രമേ ഉള്ളൂ: draft-ietf-webbotauth-httpsig-protocol, "HTTP Message Signatures for automated traffic" എന്ന title-ൽ, revision 01, dated October 29, 2026. ഇത് ഒരു Internet-Draft ആണ്, അതായത് ഇപ്പോഴും മാറാൻ കഴിയുന്ന work in progress. ഇത് RFC അല്ല.

ഒരു registry, agent card format, anonymous bot authentication, automated clients-ന്റെ IP ranges publish ചെയ്യാനുള്ള JSON format, signed agent metadata-യ്ക്കുള്ള ഒരു header എന്നിവ സംബന്ധിച്ച proposals ഉൾപ്പെടെ നിരവധി individual drafts കൂടി group-നുമായി ബന്ധപ്പെട്ടിട്ടുണ്ട്, അവ ചർച്ചയിലാണ്. Individual drafts proposals മാത്രമാണ്; ഈ തീയതിയോടെ അവയിൽ ഒന്നും group adopted ചെയ്തിട്ടില്ല.

Charter 2026-ൽ വിവിധ milestones set ചെയ്തു, specifications-നെ അംഗീകാരത്തിനായി IESG-ലേക്ക് അയക്കുന്നതിനായി. November 2026-നു വരെയും protocol document ഒരു working group draft തന്നെയാണ്. നിലവിലെ നില IETF datatracker page for the working group-ലും protocol draft-ലും പിന്തുടരാം.

HTTP Message Signatures എങ്ങനെ പ്രവർത്തിക്കുന്നു

Web Bot Auth RFC 9421, HTTP Message Signatures-ന്റെ മേൽ നിർമ്മിച്ചിരിക്കുന്നു, അത് February 2024-ൽ Proposed Standard ആയി പ്രസിദ്ധീകരിച്ചു. RFC 9421 ഒരു general mechanism ആണ്: HTTP message-ന്റെ തിരഞ്ഞെടുത്ത ഭാഗങ്ങൾ എങ്ങനെ sign ചെയ്യാമെന്നും signature headers-ൽ എങ്ങനെ carry ചെയ്യാമെന്നും അത് നിർവചിക്കുന്നു. Web Bot Auth automated clients-നായി അതിനെ profile ചെയ്യുന്നു.

ലളിതമായി പറഞ്ഞാൽ, signed agent request ഇങ്ങനെ പ്രവർത്തിക്കുന്നു:

  1. Operator ഒരു key pair സൃഷ്ടിക്കുന്നു. Private key രഹസ്യമായി സൂക്ഷിക്കുകയും public key publish ചെയ്യുകയും ചെയ്യുന്നു.
  2. Client എന്താണ് sign ചെയ്യേണ്ടതെന്ന് തിരഞ്ഞെടുക്കുന്നു. അത് request-ന്റെ components, ഉദാഹരണത്തിന് target host അല്ലെങ്കിൽ URI, creation time എന്നിവ തിരഞ്ഞെടുക്കുന്നു. Current draft authority അല്ലെങ്കിൽ target URI ഉൾക്കൊള്ളണമെന്ന് ആവശ്യപ്പെടുന്നു, അതിനാൽ ഒരു site-നുള്ള signature മറ്റൊരു site-ൽ വീണ്ടും ഉപയോഗിക്കാൻ കഴിയില്ല.
  3. Client sign ചെയ്ത് send ചെയ്യുന്നു. Request-ൽ എന്താണ് sign ചെയ്‌തത്, ഏത് key-നോടാണ് എന്നതു വിവരിക്കുന്ന ഒരു Signature-Input header ഉം, signature value ഉള്ള ഒരു Signature header ഉം ഉണ്ടാകും. Draft ഒരു web-bot-auth tag ഉപയോഗിക്കുന്നു, ഓരോ signature-ലും creation, expiry times പ്രതീക്ഷിക്കുന്നു.
  4. Site verify ചെയ്യുന്നു. അത് public key കണ്ടെത്തി, ലഭിച്ച request-ിൽ നിന്നുള്ള signed components വീണ്ടും നിർമ്മിച്ച്, signature പരിശോധിക്കുന്നു. Check pass ചെയ്താൽ, request ആ key-ന്റെ holder sign ചെയ്തതാണ്, കൂടാതെ covered parts മാറ്റം വരുത്തിയിട്ടില്ല.

Draft site-നെ signature ചോദിക്കാനും അനുവദിക്കുന്നു. An origin ഒരു Accept-Signature header, സാധാരണ ഒരു refusal സഹിതം, signed requests വേണമെന്ന് സൂചിപ്പിക്കാൻ അയയ്ക്കാം.

Key directory ആശയം

Site-ന് ശരിയായ public key കണ്ടെത്താൻ കഴിയുന്നില്ലെങ്കിൽ ഒരു signature ഉപകാരപ്രദമല്ല. Web Bot Auth അതിന് key directory ഉപയോഗിച്ച് മറുപടി നൽകുന്നു.

Current working group draft-ൽ, client ഒരു HTTPS URL അടങ്ങിയ ഒരു Signature-Agent header ചേർക്കുന്നു. ആ URL operator-ന്റെ public keys-ന്റെ ഒരു directory JSON Web Key Set ആയി serve ചെയ്യുന്നു. Site directory fetch ചെയ്ത്, signature-യിലെ key identifier-നോട് പൊരുത്തപ്പെടുന്ന key തിരഞ്ഞെടുക്കുകയും verify ചെയ്യുകയും ചെയ്യുന്നു. Draft ഒരു well-known path, /.well-known/http-message-signatures-directory, കൂടി നിർവചിക്കുന്നു, അതിലൂടെ operator തന്റെ directory serve ചെയ്യാം.

Product teams-ക്ക് ഉപകാരപ്രദമായ ആശയം URL തന്നെയാണ് identity എന്നതാണ്. ഒരു agent operator-നെ തിരിച്ചറിയുന്നത് അത് keys publish ചെയ്യുന്ന സ്ഥലത്തിലൂടെയാണ്, ഇത് signature-നെ operator നിയന്ത്രിക്കുന്ന ഒരു domain-നോട് ബന്ധിപ്പിക്കുന്നു. Key rotation പഴയ key-യുടെ കൂടെ പുതിയ key publish ചെയ്ത്, തുടർന്ന് പഴയത് remove ചെയ്ത് പ്രവർത്തിക്കുന്നു.

Verifying sites directories ശ്രദ്ധാപൂർവ്വം കൈകാര്യം ചെയ്യണം: normal HTTP rules അനുസരിച്ച് cache ചെയ്യുക, size limits ഉം timeouts ഉം set ചെയ്യുക, private network addresses-ൽ നിന്ന് fetch ചെയ്യുന്നത് ഒഴിവാക്കുക. ഇവ സാധാരണ engineering concerns ആണ്, അതിനാലാണ് verification തങ്ങൾക്ക് വേണ്ടി ചെയ്യുന്നത് ഒരു component ഉപയോഗിക്കാൻ പല teams-യും മുൻഗണന നൽകുന്നത്.

ഒരു valid signature എന്താണ് തെളിയിക്കുന്നത്, എന്തല്ല

Product policy എഴുതുന്ന ഏതൊരാൾക്കും ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗം ഇതാണ്.

ഒരു valid signature തെളിയിക്കുന്നത്:

  • Request ഒരു specific private key-ന്റെ holder sign ചെയ്‌തതാണ്.
  • ആ key operator നിയന്ത്രിക്കുന്ന directory URL-ൽ publish ചെയ്തിരിക്കുന്നു.
  • Request-ന്റെ signed parts transit-ൽ മാറ്റം വരുത്തിയിട്ടില്ല, കൂടാതെ signature അതിന്റെ validity window-ക്കുള്ളിലാണ്.

ഒരു valid signature തെളിയിക്കാത്തത്:

  • ആ agent ചെയ്യാൻ ശ്രമിക്കുന്ന action-ന് അത് authorized ആണെന്നത്. തിരിച്ചറിയാൻ കഴിയുന്നത് permission അല്ല. agent authorization കാണുക.
  • ആ agent ഒരു specific person-നുവേണ്ടിയോ, അല്ലെങ്കിൽ ആ person നൽകിയ authority-യുടെ പരിധിക്കുള്ളിലോ പ്രവർത്തിക്കുന്നു എന്നത്. delegated authority കാണുക.
  • Operator വിശ്വസനീയനാണോ, അല്ലെങ്കിൽ agent നല്ല രീതിയിൽ പെരുമാറുമോ എന്നത്. Reputation working group-ന്റെ scope-ൽ explicitly ഇല്ല.
  • Sign ചെയ്യാത്ത requests സംബന്ധിച്ച എന്തും. Unsigned traffic-ന് സ്വന്തം handling വേണം.

ഒരു valid signature-നെ who sent a request എന്നതിന്റെ ശക്തമായ evidence ആയി treat ചെയ്യുക, തുടർന്ന് നിങ്ങളുടെ സ്വന്തം access control ആ sender what that sender may do എന്ന് തീരുമാനിക്കട്ടെ.

Product teams ഇതിനെക്കുറിച്ച് എന്തുചെയ്യണം

ഒരു RFC വരുന്നത് വരെ കാത്തിരിക്കേണ്ടതില്ല. Signed agent traffic ഇപ്പോൾ തന്നെ plan ചെയ്യാവുന്ന ഒന്നാണ്, draft-ന്റെ ചില details മാറാൻ സാധ്യതയുണ്ടെന്ന് കരുതിക്കൊണ്ട്.

1. തീരുമാനിക്കുന്നതിന് മുമ്പ് measure ചെയ്യുക

നിങ്ങളുടെ traffic-ലുടെ എത്ര ഭാഗം automated ആണ്, ഏത് routes agents ഉപയോഗിക്കുന്നു, അതിൽ എത്ര signed ആണ് എന്നിവ കണ്ടെത്തുക. നിങ്ങളുടെ users-ക്ക് ഒന്നും മാറ്റമില്ലാത്ത തരത്തിൽ തുടങ്ങാൻ observation mode-ൽ ആരംഭിക്കുക.

2. Evidence-നെ policy-യിൽ നിന്ന് വേർതിരിക്കുക

What you decide to do-ൽ നിന്ന് വേറിട്ട്, evidence എന്ത് പറയുന്നു എന്ന് രേഖപ്പെടുത്തുക: verified, declared, inferred അല്ലെങ്കിൽ unknown. അത് policies വായിക്കാൻ എളുപ്പമാക്കുകയും re-instrument ചെയ്യാതെ തന്നെ അവ tighten അല്ലെങ്കിൽ relax ചെയ്യാനും അനുവദിക്കുകയും ചെയ്യും. evidence basis entry നാലു levels വിശദീകരിക്കുന്നു.

3. Verified agents-ന് നല്ല വഴി നൽകുക

അർത്ഥവത്തായിടങ്ങളിൽ, ആളുകൾക്കായി നിർമ്മിച്ച pages-ന് പകരം verified agents-ക്ക് structured content അല്ലെങ്കിൽ agent-friendly flow നൽകുക. serving AI agents structured content എന്ന guide patterns ഉൾക്കൊള്ളുന്നു.

4. Authorization നിങ്ങളുടെ code-ൽ തന്നെ സൂക്ഷിക്കുക

Signature ഉപയോഗിച്ച് ആരാണ് ചോദിക്കുന്നത് എന്ന് അറിയുക. അവർക്ക് എന്ത് ചെയ്യാമെന്ന് തീരുമാനിക്കാൻ നിങ്ങളുടെ existing permissions, scopes, confirmations എന്നിവ ഉപയോഗിക്കുക. High-impact actions-ന് request sign ചെയ്തത് ആരായാലും human confirmation വേണമെന്നുണ്ടാകാം. protecting sensitive actions without blocking agents കാണുക.

5. Unsigned, Unknown traffic-ന് plan ചെയ്യുക

Signing support agents-ലും tools-ലും വ്യത്യാസപ്പെടുന്നു, അതിനാൽ കുറച്ചുകാലം signed, unsigned requests-ന്റെ mix പ്രതീക്ഷിക്കുക. Site-wide rule ഒറ്റത്തവണ തിരഞ്ഞെടുത്തതിന് പകരം declared, inferred, Unknown traffic-ന് route അനുസരിച്ച് എന്ത് സംഭവിക്കണം എന്ന് തീരുമാനിക്കുക. handling Unknown traffic guide ഇതിലൂടെ പോകുന്നു.

Proof of Actor Web Bot Auth എങ്ങനെ ഉപയോഗിക്കുന്നു

Proof of Actor നിങ്ങളുടെ application-ൽ ഓരോ interaction-ലും ആരോ എന്തോ പ്രവർത്തിക്കുന്നു എന്ന്, Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown എന്ന നിലയിൽ, evidence basis സഹിതം പറയുന്നു. Web Bot Auth signatures അതിന്റെ ഏറ്റവും ശക്തമായ evidence sources-ലൊന്നാണ്.

ഒരു agent HTTP Message Signatures ഉപയോഗിച്ച് തന്റെ request sign ചെയ്യുമ്പോൾ, Proof of Actor signature operator-ന്റെ published key-നോട് പരിശോധിക്കുന്നു. Check pass ചെയ്താൽ, result-ിൽ നിങ്ങളുടെ ടീം review ചെയ്യാൻ കഴിയുന്ന evidence-നൊപ്പം ഒരു verified basis ഉണ്ടായിരിക്കും. ഒരു client ഒരു header-ൽ മാത്രം സ്വയം പ്രഖ്യാപിച്ചാൽ, result declared ആണ്. Conclusion behavioral അല്ലെങ്കിൽ contextual signals-ൽ ആശ്രയിച്ചാൽ, അത് inferred എന്ന് ലേബൽ ചെയ്യും. Evidence പര്യാപ്തമല്ലെങ്കിൽ, result Unknown ആണ്.

ആ context-ിൽ എന്തുചെയ്യണമെന്ന് നിങ്ങളുടെ application തീരുമാനിക്കുന്നു. Policies route, actor class, basis എന്നിവ പ്രകാരം എഴുതുന്നു, allow, adapt, challenge, review, rate-limit തുടങ്ങിയ outcomes സഹിതം. Default ആയി ഒന്നും enforced അല്ല: നിങ്ങൾ real traffic-നെതിരെ ഒരു policy preview ചെയ്ത്, നിങ്ങളുടെ own code-ൽ route by route enforce ചെയ്യുന്നു.

Founding teams Node.js middleware, Next.js, ഒരു edge integration, approved pages-ൽ browser collector, generic HTTP API, അല്ലെങ്കിൽ MCP server integration വഴിയായി evidence collect ചെയ്യാം. integrations കാണുക, കൂടാതെ verifying signed agent requests എന്ന guide practical steps നൽകുന്നു.

Proof of Actor standard-നുള്ള അതേ limit പിന്തുടരുന്നു: ഒരു verified signature request sign ചെയ്ത key ഏതാണ് എന്ന് പറയുന്നു, agent authorized ആണോ എന്ന് അല്ല. Authorization നിങ്ങളുടെ കൈയിലാണ്. evidence and limits page ഓരോ result-ും എന്താണ് support ചെയ്യുന്നത്, എന്തല്ല എന്നതു വ്യക്തമാക്കുന്നു.

തുടങ്ങുക

Proof of Actor private beta-യിലാണ്. തിരഞ്ഞെടുത്ത founding developer teams-ന് agreed usage limits-ിനുള്ളിൽ, automatic billing ഇല്ലാതെ, 12 months വരെ free access ലഭിക്കാം. Apply for early access ചെയ്ത്, signed agents ഉപയോഗിക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന routes എന്തൊക്കെയാണെന്നും അവയുമായി നിങ്ങൾ എന്ത് ചെയ്യാൻ ആഗ്രഹിക്കുന്നുവെന്നും അറിയിക്കുക.

ഡെവലപ്പർമാർക്കായി

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent അല്ലെങ്കിൽ Unknown.
basis
തെളിവ് എത്ര ശക്തമാണെന്നത്: verified, declared, inferred അല്ലെങ്കിൽ unknown.
evidence
result-ിന്റെ പിന്നിലെ signals, അതുവഴി നിങ്ങളുടെ team-ന് കാരണം കാണാൻ കഴിയും.

observation mode-ൽ ആരംഭിക്കുക: നിങ്ങളുടെ logs-ിന് ഒപ്പം results രേഖപ്പെടുത്തുക, നിങ്ങൾ ഒരു policy തിരഞ്ഞെടുക്കും വരെ ഒന്നും മാറ്റരുത്. Node.js integration guide വായിക്കുക

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

Web Bot Auth എന്താണ്?

Web Bot Auth എന്നത് IETF working group ആയ webbotauth-ന്റെ പേരും, അത് standardize ചെയ്യുന്നതുമായ സമീപനവുമാണ്: automated clients HTTP Message Signatures (RFC 9421) ഉപയോഗിച്ച് HTTP requests sign ചെയ്യുകയും അവരുടെ public keys publish ചെയ്യുകയും ചെയ്യുന്നു, അതുവഴി websites ഒരു request അയച്ച operator ആരാണെന്ന് verify ചെയ്യാം.

Web Bot Auth ഒരു finished standard ആണോ?

ഇല്ല, ഇതുവരെ അല്ല. November 2026-ലെ നിലയിൽ, പ്രധാന protocol document ആയ draft-ietf-webbotauth-httpsig-protocol revision 01-ൽ ഉള്ള working group Internet-Draft ആണ്. അത് അധിഷ്ഠിതമാകുന്ന signature format ആയ RFC 9421 ഒരു published Proposed Standard ആണ്.

ഒരു valid Web Bot Auth signature agent-ന് പ്രവർത്തിക്കാൻ അനുവാദമുണ്ടെന്ന് അർത്ഥമാക്കുമോ?

ഇല്ല. അത് request sign ചെയ്ത key ഏതാണ് എന്നും signed parts മാറ്റം വരുത്തിയില്ല എന്നും മാത്രമാണ് തെളിയിക്കുന്നത്. ആ agent data വായിക്കാമോ, ഒരു form submit ചെയ്യാമോ, അല്ലെങ്കിൽ ഒരു പ്രത്യേക user-നുവേണ്ടി പ്രവർത്തിക്കാമോ എന്നത് നിങ്ങളുടെ application ഇപ്പോഴും തീരുമാനിക്കുന്ന authorization matter ആണ്.

Product teams Web Bot Auth സ്വയം implement ചെയ്യേണ്ടതുണ്ടോ?

Sites signatures verify ചെയ്യും; automated clients അവർ തന്നെ run ചെയ്യാത്തപക്ഷം signatures sign ചെയ്യേണ്ടതില്ല. Verification-ൽ key directories fetch ചെയ്യുകയും, അവ സുരക്ഷിതമായി cache ചെയ്യുകയും, signatures പരിശോധിക്കുകയും ചെയ്യുന്നത് ഉൾപ്പെടുന്നു, അത് Proof of Actor പോലുള്ള tool നിങ്ങള്ക്കായി ചെയ്യാം.

അവരുടെ requests sign ചെയ്യാത്ത agents-നെ നാം എങ്ങനെ കൈകാര്യം ചെയ്യണം?

ലഭ്യമായ evidence അനുസരിച്ച് അവയെ കൈകാര്യം ചെയ്യുക: declared, inferred, അല്ലെങ്കിൽ Unknown. ചില സമയത്തേക്ക് signed, unsigned traffic എന്നിവയുടെ mix പ്രതീക്ഷിക്കുക, site-wide rule ഒറ്റത്തവണ ഉപയോഗിക്കുന്നതിന് പകരം route അനുസരിച്ച് ഒരു fallback set ചെയ്യുക.

Proof of Actor Web Bot Auth എങ്ങനെ ഉപയോഗിക്കുന്നു?

ഇത് HTTP Message Signatures published key-നോട് പരിശോധിക്കുന്നു, check pass ചെയ്താൽ result-നെ verified basis ആയി റിപ്പോർട്ട് ചെയ്യുന്നു. തുടർന്ന് നിങ്ങളുടെ policies-ന് verified agents-നെ declared അല്ലെങ്കിൽ Unknown traffic-ിൽ നിന്ന് വ്യത്യസ്തമായി treat ചെയ്യാം.

നിങ്ങളുടെ app ഉപയോഗിക്കുന്നത് ആരാണെന്ന് അറിയുക.

ചെറിയൊരു founding developers ഗ്രൂപ്പിനായുള്ള private beta.

Early Access നേടുകവിലകൾ കാണുക

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക