Web Bot Auth શું છે
Web Bot Auth એ IETF working group અને તેના Internet-Draft કામનું નામ છે, જે સ્વચાલિત વેબ ટ્રાફિકને authenticate કરવા વિશે છે. વિચાર સીધો છે: crawlers, AI assistants અને autonomous agents પોતાના HTTP requests પર HTTP Message Signatures (RFC 9421) નો ઉપયોગ કરીને સહી કરે છે, અને એવી ઓળખ હેઠળ જાહેર keys પ્રકાશિત કરે છે જેને તેઓ નિયંત્રિત કરે છે. પછી website ખાતરી કરી શકે છે કે request ખરેખર તે operator પાસેથી આવી છે જેને તે નામ આપે છે, user-agent string પર આધાર રાખ્યા વગર, જેને કોઈ પણ નકલ કરી શકે છે. આનો product team માટે શું અર્થ થાય છે તે માટે Web Bot Auth for product teams જુઓ; implementation પગલાં માટે how to verify signed AI agent requests માર્ગદર્શિકા જુઓ.
November 2026 સુધી, working group's મુખ્ય દસ્તાવેજ 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 કેવી રીતે શોધવામાં આવે છે, request ના કયા components પર સહી થવી જોઈએ, અને કયા headers operator information લઈ જાય છે, જેવી વિગતો version થી version બદલાઈ શકે છે. Implementers એ કોઈ snapshot નહીં, current drafts ને અનુસરવા જોઈએ.
તે કેમ મહત્વનું છે
Websites અને APIs લાંબા સમયથી bot ને user-agent strings અને IP ranges દ્વારા ઓળખે છે. બંનેની મર્યાદા છે: user-agent strings સરળતાથી spoof થઈ શકે છે (user-agent spoofing જુઓ), અને IP ranges બદલાતી રહે છે તેમજ cloud providersમાં વહેંચાયેલી હોય છે. જેમ જેમ AI agents લોકોની તરફથી browse કરવાનું, APIs call કરવાનું અને MCP servers નો ઉપયોગ કરવાનું શરૂ કરે છે, applications ને સહકાર આપતા સ્વચાલિત clients ને anonymous ones થી અલગ ઓળખવાની વધુ મજબૂત રીત જોઈએ.
સહી કરેલા requests એ વધુ મજબૂત આધાર આપે છે. Verified signature application ને જાણીતા operator ને સતત ઓળખવાની, માનવ-સમાન interface ને બદલે તેને structured path આપવાની, અને તેની activity ને ચોક્કસ રીતે માપવાની તક આપે છે.
ઊંચા સ્તરે તે કેવી રીતે કાર્ય કરે છે
- Operator key pair બનાવે છે અને public key ને પોતાની ઓળખ સાથે જોડાયેલી જગ્યાએ પ્રકાશિત કરે છે, સામાન્ય રીતે પોતાના domain હેઠળનો
http-message-signatures-directorywell-known path. - દરેક request માં પસંદ કરેલા request components ને આવરી લેતા
Signature-InputઅનેSignatureheaders, સાથે key identifier, અને key directory તરફ સંકેત આપતોSignature-Agentheader હોય છે. - પ્રાપ્ત કરનાર site operator ની પ્રકાશિત keys ને fetch અથવા cache કરે છે, signature base ફરી બનાવે છે અને signature verify કરે છે.
- સફળતા પર, site જાણે છે કે request તે key ધારક દ્વારા બનાવવામાં આવ્યો હતો, જે તે પ્રકાશિત identifier સાથે જોડાયેલ છે.
તે શું સ્થાપિત કરે છે, અને શું નથી કરતું
Web Bot Auth signature સ્વચાલિત client ને authenticate કરે છે. તે નીચેના પ્રશ્નોના જવાબ આપતું નથી:
- operator ને તે જે માગે છે તે કરવા દેવામાં આવ્યું છે કે નહીં (agent authorization),
- કોઈ વ્યક્તિએ action સૂચવ્યો કે મંજૂર કર્યો હતો કે નહીં (delegated authority),
- action સુરક્ષિત છે કે પાછું મળેલું content યોગ્ય રીતે વપરાશે કે નહીં.
આ બધું receiving application ની પોતાની authentication, authorization અને policy ના નિર્ણયો તરીકે જ રહે છે. અમારી blog post what signed AI agent requests prove, and what they don't આ boundary ને સમજાવે છે.
સામાન્ય ગેરસમજો
- "દરેક bot ટૂંક સમયમાં સહી કરશે." Adoption client પ્રમાણે વધે છે. લાંબા સમય સુધી applications ને signed, declared અને anonymous traffic નો મિશ્રણ મળશે, એટલે દરેકને સંભાળવાની સ્પષ્ટ રીત જોઈએ.
- "Signature bot ને સારું બનાવે છે." તે bot ને જાણીતું બનાવે છે. જાણીતું હોવું policy માટેનો આરંભબિંદુ છે, policy પોતે નથી.
- "Draft અંતિમ છે." તે બદલાતો Internet-Draft છે. હાલના લખાણ પર આધારિત વિકાસ કરો અને સુધારાઓની અપેક્ષા રાખો.
Proof of Actor સાથે તેનો સંબંધ
Proof of Actor માન્ય signature ને evidence તરીકે, basis Verified સાથે, તે key અને identifier સુધી સીમિત કરીને લે છે જે તે સાબિત કરે છે. તે તેને declared names અને inferred signals થી અલગ રાખે છે, અને identity ને permission માં ક્યારેય ફેરવતું નથી. Proof of Actor, standards પરિપક્વ થતાં signed requests verify કરવા માટે રચાયેલ છે; Route માં તમારી પોતાની policies નક્કી કરે છે કે verified agent શું કરી શકે.
આ APIs અને MCP servers માં કેવી રીતે બંધાય છે તે જુઓ, અથવા apply for early access.
સ્ત્રોતો
- IETF Web Bot Auth working group: charter, chairs અને status
- Web Bot Auth working group documents: current working group અને સંબંધિત drafts
- 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 આધારિત છે