Web Bot Auth

Web Bot Auth ಎಂದರೇನು

Web Bot Auth ಎಂಬುದು ಸ್ವಯಂಚಾಲಿತ ವೆಬ್ ಟ್ರಾಫಿಕ್‌ನ ದೃಢೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ IETF working group ಮತ್ತು ಅದರ Internet-Draft ಕೆಲಸದ ಹೆಸರು. ಕಲ್ಪನೆ ಸರಳವಾಗಿದೆ: crawlers, AI assistants ಮತ್ತು autonomous agents ತಮ್ಮ HTTP ವಿನಂತಿಗಳಿಗೆ HTTP Message Signatures (RFC 9421) ಬಳಸಿ ಸಹಿ ಹಾಕುತ್ತಾರೆ, ಮತ್ತು ಆ ಸಹಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವ public keys ಅನ್ನು ತಾವು ನಿಯಂತ್ರಿಸುವ ಗುರುತು ಅಡಿಯಲ್ಲಿ ಪ್ರಕಟಿಸುತ್ತಾರೆ. ನಂತರ ಒಂದು ವೆಬ್‌ಸೈಟ್, ಯಾರಾದರೂ ನಕಲಿಸಬಹುದಾದ user-agent string ಮೇಲೆ ನಂಬಿಕೆ ಇಡುವುದಕ್ಕಿಂತ, ಆ ವಿನಂತಿ ನಿಜವಾಗಿಯೂ ಅದು ಹೆಸರಿಸುವ operator ನಿಂದಲೇ ಬಂದಿದೆಯೇ ಎಂಬುದನ್ನು ದೃಢಪಡಿಸಬಹುದು. ಇದು product team ಗೆ ಏನು ಅರ್ಥ ನೀಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ Web Bot Auth for product teams ನೋಡಿ; ಅನುಷ್ಠಾನ ಹಂತಗಳಿಗಾಗಿ signed AI agent requests ಅನ್ನು ಹೇಗೆ verify ಮಾಡುವುದು ಮಾರ್ಗದರ್ಶಿ ನೋಡಿ.

November 2026ರ ಸ್ಥಿತಿಗೆ, working group's core 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 ಇದನ್ನು ಸಂಬಂಧಿತ ವೈಯಕ್ತಿಕ drafts ಜೊತೆಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಇವು Internet-Drafts, ಅಂದರೆ ಇವು ಕೆಲಸ ನಡೆಯುತ್ತಿರುವ ದಾಖಲೆಗಳು. keys ಹೇಗೆ discover ಆಗುತ್ತವೆ, ಯಾವ request components ಸಹಿ ಹೊಂದಿರಬೇಕು, ಮತ್ತು ಯಾವ headers operator ಮಾಹಿತಿಯನ್ನು ಹೊರುತ್ತವೆ ಎಂಬ ವಿವರಗಳು ಆವೃತ್ತಿಗಳ ನಡುವೆ ಬದಲಾಗಬಹುದು. Implementers ಗಳು ಯಾವುದೇ snapshot ಗಿಂತ ಪ್ರಸ್ತುತ drafts ಅನ್ನು ಅನುಸರಿಸಬೇಕು.

ಇದು ಏಕೆ ಮುಖ್ಯ

ವೆಬ್‌ಸೈಟ್‌ಗಳು ಮತ್ತು APIs ಬಹುಕಾಲದಿಂದ user-agent strings ಮತ್ತು IP ranges ಮೂಲಕ bots ಅನ್ನು ಗುರುತಿಸುತ್ತಿವೆ. ಎರಡಕ್ಕೂ ಮಿತಿಗಳು ಇವೆ: user-agent strings ಅನ್ನು ಸುಲಭವಾಗಿ spoof ಮಾಡಬಹುದು (user-agent spoofing ನೋಡಿ), ಮತ್ತು IP ranges ಕಾಲಕಾಲಕ್ಕೆ ಬದಲಾಗುತ್ತವೆ ಹಾಗೂ cloud providers ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲ್ಪಡುತ್ತವೆ. AI agents ಜನರ ಪರವಾಗಿ browse ಮಾಡಲು, APIs call ಮಾಡಲು ಮತ್ತು MCP servers ಬಳಸಲು ಆರಂಭಿಸುವಾಗ, applications ಗೆ ಸಹಕರಿಸುವ automated clients ಮತ್ತು anonymous clients ಗಳನ್ನು ವಿಭಜಿಸುವ ಹೆಚ್ಚು ಬಲವಾದ ಮಾರ್ಗ ಅಗತ್ಯವಾಗುತ್ತದೆ.

Signed requests ಆ ಬಲವಾದ ನೆಲೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ. Verified signature ಒಂದು application ಗೆ known operator ಅನ್ನು ಸತತವಾಗಿ ಗುರುತಿಸಲು, human-shaped interface ಬದಲಿಗೆ structured path ನೀಡಲು, ಮತ್ತು ಅದರ activity ಯನ್ನು ನಿಖರವಾಗಿ ಅಳೆಯಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.

ಇದು ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

1. Operator ಒಂದು key pair ಅನ್ನು generate ಮಾಡಿ, ತನ್ನ ಗುರುತಿಗೆ ಜೋಡಿಸಲಾದ ಸ್ಥಳದಲ್ಲಿ public key ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನ 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 ಪ್ರಕಟಿಸಿದ keys ಗಳನ್ನು fetch ಮಾಡುತ್ತದೆ ಅಥವಾ cache ಮಾಡುತ್ತದೆ, signature base ಅನ್ನು ಮರುನಿರ್ಮಿಸಿ signature ಅನ್ನು verify ಮಾಡುತ್ತದೆ.
4. ಯಶಸ್ವಿಯಾದರೆ, ಆ ವಿನಂತಿ ಆ published identifier ಗೆ ಸಂಬಂಧಿಸಿದ key holder ಮೂಲಕ ಉತ್ಪಾದಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು site ಗೆ ಗೊತ್ತಾಗುತ್ತದೆ.

ಇದು ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಏನನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ

Web Bot Auth signature automated client ಅನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ:

• operator ಕೇಳಿರುವುದನ್ನು ಮಾಡಲು ಅನುಮತಿ ಹೊಂದಿದೆಯೇ (agent authorization),
• ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಆ action ಅನ್ನು ಸೂಚಿಸಿದ್ದಾರೇ ಅಥವಾ ಅನುಮೋದಿಸಿದ್ದಾರೇ (delegated authority),
• ಆ action ಸುರಕ್ಷಿತವೇ ಅಥವಾ ಮರಳಿದ content ಅನ್ನು ಸೂಕ್ತವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆಯೇ.

ಇವುಗಳೆಲ್ಲಾ ಸ್ವೀಕರಿಸುವ application ನ ಸ್ವಂತ authentication, authorization ಮತ್ತು policy ಗೆ ಸೇರಿದ ನಿರ್ಧಾರಗಳಾಗಿರುತ್ತವೆ. signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಏನು ಅಲ್ಲ ಎಂಬ ನಮ್ಮ blog post ಈ ಗಡಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು

• "ಶೀಘ್ರದಲ್ಲೇ ಪ್ರತಿಯೊಂದು bot ಸಹಿ ಹಾಕುತ್ತದೆ." Adoption client ನಿಂದ client ಗೆ ಹೆಚ್ಚುತ್ತದೆ. ದೀರ್ಘಕಾಲ applications ಗೆ signed, declared ಮತ್ತು anonymous traffic ಗಳ ಮಿಶ್ರಣ ಕಾಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದನ್ನೂ ನಿರ್ವಹಿಸಲು ಸ್ಪಷ್ಟ ಮಾರ್ಗ ಬೇಕಾಗುತ್ತದೆ.
• "Signature bot ಅನ್ನು ಉತ್ತಮವಾಗಿಸುತ್ತದೆ." ಅದು bot ಅನ್ನು known ಆಗಿಸುತ್ತದೆ. Known ಆಗಿರುವುದು policy ಗೆ ಆರಂಭಬಿಂದು, policy ತಾನೇ ಅಲ್ಲ.
• "Draft ಅಂತಿಮವಾಗಿದೆ." ಅದು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿರುವ Internet-Draft. ಪ್ರಸ್ತುತ ಪಠ್ಯದ ಆಧಾರದಲ್ಲಿ ನಿರ್ಮಿಸಿ ಮತ್ತು ತಿದ್ದುಪಡಿಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ.

Proof of Actor ಹೇಗೆ ಸಂಬಂಧಿಸುತ್ತದೆ

Proof of Actor ಒಂದು validated signature ಅನ್ನು ಅದು ಸಾಬೀತುಪಡಿಸುವ key ಮತ್ತು identifier ಗೆ ಸೀಮಿತವಾದ verified basis ಇರುವ evidence ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಅದು declared names ಮತ್ತು inferred signals ಗಳಿಂದ ಅದನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು identity ಅನ್ನು permission ಆಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ. ಮಾನದಂಡಗಳು ಪರಿಪಕ್ವವಾಗುತ್ತಿದ್ದಂತೆ signed requests ಅನ್ನು verify ಮಾಡಲು Proof of Actor ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ; Route ನಲ್ಲಿ ನಿಮ್ಮ own policies ಯಾವ verified agent ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ.

ಇದು APIs ಮತ್ತು MCP servers ಗಳಲ್ಲಿ ಹೇಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ, ಅಥವಾ early access ಗೆ apply ಮಾಡಿ.

ಮೂಲಗಳು

• IETF Web Bot Auth working group: charter, chairs ಮತ್ತು ಸ್ಥಿತಿ
• Web Bot Auth working group documents: ಪ್ರಸ್ತುತ working group ಮತ್ತು ಸಂಬಂಧಿತ drafts
• 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