ವಿವರಣೆ

ಉತ್ಪನ್ನ ತಂಡಗಳಿಗಾಗಿ Web Bot Auth: ಸಹಿಯಾದ agent ವಿನಂತಿಗಳು ನಿಮ್ಮ roadmap ಗೆ ಏನು ಅರ್ಥ ನೀಡುತ್ತವೆ

AI agents ಮತ್ತು crawlers ಗೆ ಯಾರಾದರೂ ನಕಲಿಸಬಹುದಾದ User-Agent string ಮೇಲೆ ಅವಲಂಬಿಸದೆ ತಾವು ಯಾರು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಮಾರ್ಗ ಹೆಚ್ಚಾಗಿ ಬೇಕಾಗುತ್ತಿದೆ. IETF Web Bot Auth ಕೆಲಸವು ಅದನ್ನು ಮಾನಕೀಕರಿಸುವ ಪ್ರಮುಖ ಪ್ರಯತ್ನವಾಗಿದೆ. ಇದು ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ನಾಯಕರಿಗಾಗಿ ಸರಳ ವಿವರಣೆ: ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, November 2026 ರ ವೇಳೆಗೆ ಇದರ ಸ್ಥಿತಿ ಏನು, ಮತ್ತು ಇದಕ್ಕಾಗಿ ಹೇಗೆ ಯೋಜಿಸಬೇಕು.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅನ್ವೇಷಿಸಿ

ರಚನೆ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ಸಂಕ್ಷಿಪ್ತ ಉತ್ತರ

Web Bot Auth ಎನ್ನುವುದು IETF ಕೆಲಸವಾಗಿದ್ದು, AI agents ಸಹಿತ automated clients ಗಳು ತಮ್ಮ HTTP ವಿನಂತಿಗಳಿಗೆ HTTP Message Signatures (RFC 9421) ಮೂಲಕ ಸಹಿ ಹಾಕಲು ಮತ್ತು ಕೀಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಅವಕಾಶ ನೀಡುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿದೆ, ಇದರಿಂದ sites ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಮಾನ್ಯ ಸಹಿ ಒಂದು ವಿನಂತಿಗೆ ಯಾವ ಕೀ ಸಹಿ ಹಾಕಿತು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಆದರೆ agent ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅಧಿಕಾರ ಹೊಂದಿದೆಯೇ ಎಂಬುದನ್ನು ಅಲ್ಲ. November 2026 ರ ವೇಳೆಗೆ ಮೂಲ ನಿರ್ದಿಷ್ಟತೆ working group Internet-Draft ಆಗಿದೆ, ಆದ್ದರಿಂದ ಉತ್ಪನ್ನ ತಂಡಗಳು ಸಹಿಗಳನ್ನು ಬಲವಾದ ಸಾಕ್ಷ್ಯವಾಗಿ ಬಳಸಲು ಸಿದ್ಧರಾಗಬೇಕು, ಆದರೆ ಇನ್ನೂ ಸಹಿಯಿಲ್ಲದ traffic ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಲೇ ಇರಬೇಕು.

ವರ್ಷಗಳ ಕಾಲ, automated client ಒಂದು website ಗೆ ತಾನು ಯಾರು ಎಂದು ತಿಳಿಸುವ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ User-Agent header ನಲ್ಲಿರುವ ಹೆಸರು ಮತ್ತು, ಕೆಲವು ದೊಡ್ಡ operators ಗಾಗಿ, ಪ್ರಕಟಿತ IP address ಗಳ ಪಟ್ಟಿ ಅಥವಾ reverse DNS check ಆಗಿತ್ತು. ಹೆಸರುಗಳನ್ನು ನಕಲಿಸುವುದು ಸುಲಭ. Network ಪಟ್ಟಿಗಳು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುವ operators ಗಳನ್ನಷ್ಟೇ ಒಳಗೊಂಡಿರುತ್ತವೆ. AI agents ಗಳು ವೆಬ್‌ನಾದ್ಯಂತ ನಿಜವಾದ ಜನರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಆರಂಭಿಸುವಂತೆ, ಆ ಅಂತರವು security ಸಮಸ್ಯೆಯಷ್ಟೇ ಅಲ್ಲ, product ಸಮಸ್ಯೆಯೂ ಆಗಿದೆ.

Web Bot Auth ಅದನ್ನು ಮುಚ್ಚಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರಮುಖ ಪ್ರಯತ್ನವಾಗಿದೆ. ಇದು automated clients ಗಳು ತಾವು ನಿಯಂತ್ರಿಸುವ ಮತ್ತು ಪ್ರಕಟಿಸುವ key ಮೂಲಕ ತಮ್ಮ ವಿನಂತಿಗಳಿಗೆ ಸಹಿ ಹಾಕಲು ಮಾರ್ಗ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ site ಒಂದು ಹೆಸರನ್ನು ನಂಬುವ ಬದಲು ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಈ ವಿವರಣೆ specifications ಅನ್ನು ಆರಂಭದಿಂದ ಅಂತ್ಯವರೆಗೆ ಓದದೆ, ಅದು ಏನು, ಏನು ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಏನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ತಿಳಿಯಬೇಕಾದ product managers ಮತ್ತು engineering leads ಗಾಗಿ.

ಸಂಕ್ಷಿಪ್ತ ರೂಪ

ಇದು ಏನು: IETF working group, webbotauth, ಮತ್ತು automated HTTP clients ಗಳನ್ನು authenticate ಮಾಡಲು ಅದು ಮಾನಕೀಕರಿಸುತ್ತಿರುವ ವಿಧಾನ.
ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: client HTTP Message Signatures (RFC 9421) ಬಳಸಿ ಪ್ರತಿ ವಿನಂತಿಯ ಭಾಗಗಳಿಗೆ ಸಹಿ ಹಾಕುತ್ತದೆ ಮತ್ತು ತನ್ನ public keys ಗಳ directory ಗೆ ಸೂಚಿಸುತ್ತದೆ. site ಕೀ ಅನ್ನು ಪಡೆದು ಸಹಿಯನ್ನು verify ಮಾಡುತ್ತದೆ.
ಇದು ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ಯಾವ ಕೀ ವಿನಂತಿಗೆ ಸಹಿ ಹಾಕಿತು, ಮತ್ತು ಸಹಿಯಾದ ಭಾಗಗಳು ಸಾಗಣೆಯಲ್ಲಿ ಬದಲಾಯಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂಬುದು.
ಇದು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ: agent ಕೇಳುತ್ತಿರುವುದನ್ನು ಮಾಡಲು ಅದಕ್ಕೆ authorization ಇದೆ ಎಂಬುದು, ಅದು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು, ಅಥವಾ ಅದು ಸದಾ ಸರಿಯಾಗಿ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದು.
November 2026 ರ ವೇಳೆಯ ಸ್ಥಿತಿ: RFC 9421 ಪ್ರಕಟಿತ Proposed Standard ಆಗಿದೆ. Web Bot Auth protocol document ಇನ್ನೂ working group Internet-Draft ಆಗಿದ್ದು, RFC ಆಗಿಲ್ಲ.
ಏನು ಮಾಡಬೇಕು: ಮಾನ್ಯ ಸಹಿಗಳನ್ನು ಬಲವಾದ ಸಾಕ್ಷ್ಯವಾಗಿ ಪರಿಗಣಿಸಲು ಯೋಜಿಸಿ, ಸಹಿಯಿಲ್ಲದ traffic ನ್ನು ನಿರ್ವಹಿಸುತ್ತಲೇ ಇರಿ, ಮತ್ತು authorization ನಿರ್ಧಾರಗಳನ್ನು ನಿಮ್ಮದೇ code ನಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ.

IETF Web Bot Auth ಕೆಲಸ ಏನು

IETF Web Bot Auth working group ಅನ್ನು automated clients ಗಳನ್ನು cryptographically authenticate ಮಾಡುವ ವಿಧಾನಗಳನ್ನು ಮತ್ತು websites ಗಳಿಗೆ ಅವುಗಳ ಹಿಂದೆ ಇರುವ operators ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ನೀಡುವ ವಿಧಾನಗಳನ್ನು ಮಾನಕೀಕರಿಸಲು charter ನೀಡಿದೆ. ಈ charter ಮುಖ್ಯವಾಗಿ ಜನರಿಗೆ ಸೇವೆ ನೀಡುವ sites ಗಳ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ವ್ಯಾಪಕವಾದ client ಗಳನ್ನು scope ಒಳಗೆ ಹೆಸರಿಸುತ್ತದೆ: crawlers, web archivers, link checkers, AI training crawlers ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ AI agents.

ಈ charter ನಲ್ಲಿನ ಎರಡು ಹೊರತಾಗಿಸುವಿಕೆಗಳು ಉತ್ಪನ್ನ ತಂಡಗಳಿಗೆ ಗಮನಾರ್ಹ. End-user authentication scope ಹೊರಗಿದೆ, ಆದ್ದರಿಂದ ಇದು ವ್ಯಕ್ತಿಯನ್ನು sign in ಮಾಡಿಸುವ ಮಾರ್ಗವಲ್ಲ. Bot reputation ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದೂ scope ಹೊರಗಿದೆ, ಆದ್ದರಿಂದ standard ನಿಮಗೆ ವಿನಂತಿಗೆ ಯಾರು ಸಹಿ ಹಾಕಿದರು ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ, ಆದರೆ ಆ operator ನಂಬಿಕಸ್ಥನಾ ಎಂಬುದನ್ನು ಅಲ್ಲ.

ಚಾರ್ಟರ್ ಮೂರು ವಿಧದ deliverables ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ:

ಜನರಿಗೆ ನಿರ್ಮಿಸಲಾದ websites ಗಳಿಗೆ automated clients ಗಳನ್ನು authenticate ಮಾಡುವ ತಂತ್ರಗಳ ಕುರಿತು Standards track documents.
domain name ಅಥವಾ URL ನಂತಹ ಈಗಿರುವ identifier ಬಳಸಿ requesting bot ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ನೀಡುವ ಕುರಿತು Standards track documents.
key management, lifecycle ಮತ್ತು deployment ನಂತಹ operational ವಿಷಯಗಳ ಕುರಿತು Best current practice ಅಥವಾ informational documents.

November 2026 ರ ವೇಳೆಗೆ documents ಗಳ ಸ್ಥಿತಿ

November 2026 ರ ವೇಳೆಗೆ, working group ಗೆ ಒಂದು adopted working group document ಇದೆ: draft-ietf-webbotauth-httpsig-protocol, ಶೀರ್ಷಿಕೆ "HTTP Message Signatures for automated traffic", revision 01, ದಿನಾಂಕ October 29, 2026. ಇದು Internet-Draft ಆಗಿದ್ದು, ಇದರರ್ಥ ಇದು ಕೆಲಸ ನಡೆಯುತ್ತಿರುವ ಹಂತದಲ್ಲಿದೆ ಮತ್ತು ಇನ್ನೂ ಬದಲಾಗಬಹುದು. ಇದು RFC ಅಲ್ಲ.

ಗುಂಪಿನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಹಲವಾರು individual drafts ಗಳೂ ಚರ್ಚೆಯಲ್ಲಿವೆ, ಅದರಲ್ಲಿ registry ಮತ್ತು agent card format ಕುರಿತು ಪ್ರಸ್ತಾಪಗಳು, anonymous bot authentication, automated clients ಗಳ IP ranges ಪ್ರಕಟಿಸಲು JSON format, ಮತ್ತು signed agent metadata ಗಾಗಿ header ಸೇರಿವೆ. Individual drafts ಗಳು ಪ್ರಸ್ತಾಪಗಳು ಮಾತ್ರ; ಈ ದಿನಾಂಕದ ವೇಳೆಗೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಗುಂಪು ಅಂಗೀಕರಿಸಿಲ್ಲ.

ಚಾರ್ಟರ್ 2026 ರಲ್ಲಿ IESG ಗೆ approval ಗಾಗಿ specifications ಕಳುಹಿಸುವ milestones ಗಳನ್ನು ಹೊಂದಿತ್ತು. November 2026 ರ ವೇಳೆಗೆ, protocol document ಇನ್ನೂ working group draft ಆಗಿದೆ. ನೀವು working group ಗಾಗಿ IETF datatracker page ಮತ್ತು protocol draft ನಲ್ಲಿ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಅನುಸರಿಸಬಹುದು.

HTTP Message Signatures ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ

Web Bot Auth RFC 9421, HTTP Message Signatures ಮೇಲೆ ಆಧಾರಿತವಾಗಿದೆ, ಇದು February 2024 ರಲ್ಲಿ Proposed Standard ಆಗಿ ಪ್ರಕಟಿಸಲಾಯಿತು. RFC 9421 ಒಂದು ಸಾಮಾನ್ಯ mechanism ಆಗಿದೆ: ಇದು HTTP message ನ ಆಯ್ದ ಭಾಗಗಳಿಗೆ ಹೇಗೆ ಸಹಿ ಹಾಕುವುದು ಮತ್ತು signature ಅನ್ನು headers ನಲ್ಲಿ ಹೇಗೆ ಸಾಗಿಸುವುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Web Bot Auth ಅದನ್ನು automated clients ಗಳಿಗಾಗಿ profile ಮಾಡುತ್ತದೆ.

ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸಹಿಯಾದ agent ವಿನಂತಿ ಹೀಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

Operator ಒಂದು key pair ರಚಿಸುತ್ತದೆ. ಅದು private key ಅನ್ನು ರಹಸ್ಯವಾಗಿಡುತ್ತದೆ ಮತ್ತು public key ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ.
Client ಏನು ಸಹಿ ಹಾಕಬೇಕು ಎಂದು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಅದು request ನ ಭಾಗಗಳನ್ನು, ಉದಾಹರಣೆಗೆ target host ಅಥವಾ URI ಮತ್ತು creation time, ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಪ್ರಸ್ತುತ draft authority ಅಥವಾ target URI ಅನ್ನು ಒಳಗೊಳ್ಳುವಂತೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು site ಗಾಗಿ ಮಾಡಿದ signature ಅನ್ನು ಸರಳವಾಗಿ ಮತ್ತೊಂದು site ಗೆ replay ಮಾಡಲಾಗುವುದಿಲ್ಲ.
Client ಸಹಿ ಹಾಕಿ ಕಳುಹಿಸುತ್ತದೆ. ವಿನಂತಿ ಯಾವುದು ಸಹಿ ಹಾಕಲಾಗಿದೆ ಮತ್ತು ಯಾವ key ಬಳಕೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ Signature-Input header ಮತ್ತು signature value ಹೊಂದಿರುವ Signature header ಅನ್ನು ಹೊರುತ್ತದೆ. draft web-bot-auth tag ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ signature ಗೆ creation ಮತ್ತು expiry times ಅನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ.
Site ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದು public key ಅನ್ನು ಕಂಡುಹಿಡಿದು, ಪಡೆದ request ನಿಂದ ಸಹಿಯಾದ ಘಟಕಗಳನ್ನು ಪುನರ್ ರಚಿಸಿ, ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದರೆ, ವಿನಂತಿಗೆ ಆ key ನ holder ಸಹಿ ಹಾಕಿದ್ದಾನೆ ಮತ್ತು ಒಳಗೊಂಡ ಭಾಗಗಳು ಬದಲಾಯಿಸಲ್ಪಟ್ಟಿಲ್ಲ.

Draft ಒಂದೆ site ಗೆ ಸಹಿಯನ್ನು ಕೇಳುವ ಅವಕಾಶವನ್ನೂ ನೀಡುತ್ತದೆ. ಒಂದು origin ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಕರಣೆಯೊಂದಿಗೆ Accept-Signature header ಕಳುಹಿಸಿ, ಅದು ಸಹಿಯಾದ ವಿನಂತಿಗಳನ್ನು ಬಯಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸಬಹುದು.

ಕೀ ಡೈರೆಕ್ಟರಿ ಕಲ್ಪನೆ

Site ಗೆ ಸರಿಯಾದ public key ಸಿಗದೇ ಇದ್ದರೆ ಸಹಿ ಉಪಯುಕ್ತವಾಗುವುದಿಲ್ಲ. Web Bot Auth ಇದಕ್ಕೆ key directory ಮೂಲಕ ಉತ್ತರಿಸುತ್ತದೆ.

ಪ್ರಸ್ತುತ working group draft ನಲ್ಲಿ, client ಒಂದು HTTPS URL ಹೊಂದಿರುವ Signature-Agent header ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆ URL operator ನ public keys ಗಳ directory ಯಾಗಿ JSON Web Key Set ರೂಪದಲ್ಲಿ ಸೇವೆ ನೀಡುತ್ತದೆ. Site directory ಅನ್ನು ಪಡೆದು, signature ನಲ್ಲಿನ key identifier ಗೆ ಹೊಂದುವ key ಅನ್ನು ಆಯ್ಕೆಮಾಡಿ, verify ಮಾಡುತ್ತದೆ. Draft ಒಂದು well-known path /.well-known/http-message-signatures-directory ಅನ್ನು ಕೂಡ ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಅಲ್ಲಿ operator ತನ್ನ directory ಯನ್ನು ಸೇವೆ ಮಾಡಬಹುದು.

ಉತ್ಪನ್ನ ತಂಡಗಳಿಗೆ ಉಪಯುಕ್ತವಾದ ಕಲ್ಪನೆಯೆಂದರೆ URL ಗುರುತಾಗಿ ಮಾರ್ಪಡುತ್ತದೆ. ಒಂದು agent operator ತನ್ನ keys ಗಳನ್ನು ಪ್ರಕಟಿಸುವ ಸ್ಥಳದಿಂದ ಗುರುತಿಸಲ್ಪಡುತ್ತದೆ, ಇದು signature ಅನ್ನು operator ನಿಯಂತ್ರಿಸುವ domain ಗೆ ಜೋಡಿಸುತ್ತದೆ. Key rotation ಹೊಸ key ಅನ್ನು ಹಳೆಯದೊಂದಿಗೇ ಪ್ರಕಟಿಸುವ ಮೂಲಕ ನಡೆಯುತ್ತದೆ, ನಂತರ ಹಳೆಯ key ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ಪರಿಶೀಲಿಸುವ sites ಗಳು directories ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ವಹಿಸಬೇಕು: ಸಾಮಾನ್ಯ HTTP ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ cache ಮಾಡುವುದು, size limits ಮತ್ತು timeouts ಹೊಂದಿಸುವುದು, ಮತ್ತು private network addresses ಗಳಿಂದ fetch ಮಾಡದಿರುವುದು. ಇವು ಸಾಮಾನ್ಯ ಎಂಜಿನಿಯರಿಂಗ್ concerns ಆಗಿದ್ದು, ಅದಕ್ಕೇ ಅನೇಕ ತಂಡಗಳು verification ಅನ್ನು ತಮ್ಮ ಪರವಾಗಿ ಮಾಡುವ component ಅನ್ನು ಇಷ್ಟಪಡುತ್ತವೆ.

ಮಾನ್ಯ ಸಹಿ ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

ತಮ್ಮ product policy ಬರೆಯುತ್ತಿರುವ ಯಾರಿಗೂ ಇದು ಅತ್ಯಂತ ಪ್ರಮುಖ ವಿಭಾಗ.

ಮಾನ್ಯ ಸಹಿ ಸಾಬೀತುಪಡಿಸುವುದು:

ವಿನಂತಿಗೆ ನಿರ್ದಿಷ್ಟ private key ನ holder ಸಹಿ ಹಾಕಿದ್ದಾನೆ.
ಆ key ಅನ್ನು operator ನಿಯಂತ್ರಿಸುವ directory URL ನಲ್ಲಿ ಪ್ರಕಟಿಸಲಾಗಿದೆ.
ವಿನಂತಿಯ ಸಹಿಯಾದ ಭಾಗಗಳು ಸಾಗಣೆಯಲ್ಲಿ ಬದಲಾಯಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಮತ್ತು signature ತನ್ನ ಮಾನ್ಯತಾ ವಿಂಡೋ ಒಳಗಿದೆ.

ಮಾನ್ಯ ಸಹಿ ಸಾಬೀತುಪಡಿಸದಿರುವುದು:

agent‌ಗೆ action ನಡೆಸಲು authorization ಇದೆ ಎಂಬುದು. ಗುರುತಿಸಬಹುದಾಗಿರುವುದು ಅನುಮತಿ ಅಲ್ಲ. agent authorization ನೋಡಿ.
agent ನಿರ್ದಿಷ್ಟ ವ್ಯಕ್ತಿಯ ಪರವಾಗಿ ಅಥವಾ ಆ ವ್ಯಕ್ತಿ ನೀಡಿದ ಅಧಿಕಾರದ ಒಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು. delegated authority ನೋಡಿ.
operator ನಂಬಿಕಸ್ಥನಾಗಿದ್ದಾನೆ ಅಥವಾ agent ಚೆನ್ನಾಗಿ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದು. Reputation working group scope ಹೊರಗಿದೆ.
ಸಹಿಯಾಗಿಲ್ಲದ ವಿನಂತಿಗಳ ಕುರಿತು ಏನನ್ನೂ. ಸಹಿಯಿಲ್ಲದ traffic ಗೆ ಇನ್ನೂ ತನ್ನದೇ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿದೆ.

ಮಾನ್ಯ ಸಹಿಯನ್ನು ಯಾರು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದರು ಎಂಬುದರ ಬಲವಾದ ಸಾಕ್ಷ್ಯವಾಗಿ ಪರಿಗಣಿಸಿ, ನಂತರ ನಿಮ್ಮದೇ access control ಗೆ ಆ sender ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಬಿಡಿ.

ಉತ್ಪನ್ನ ತಂಡಗಳು ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬೇಕು

RFC ಗಾಗಿ ಕಾಯದೆ ನೀವು ಯೋಜಿಸಬಹುದು. ಸಹಿಯಾದ agent traffic ಈಗಲೇ ನೀವು ಸಿದ್ಧಪಡಿಸಬಹುದಾದ ವಿಷಯವಾಗಿದೆ, draft ನ ಕೆಲವು ವಿವರಗಳು ಬದಲಾಗಬಹುದು ಎಂಬ ನಿರೀಕ್ಷೆಯೊಂದಿಗೆ.

1. ನಿರ್ಧರಿಸುವ ಮೊದಲು ಅಳೆಯಿರಿ

ನಿಮ್ಮ traffic ನ ಎಷ್ಟು ಭಾಗ automated ಆಗಿದೆ, agents ಯಾವ routes ಬಳಸುತ್ತವೆ, ಮತ್ತು ಅದರಲ್ಲಿ ಎಷ್ಟು sign ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ. ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಏನೂ ಬದಲಾಗದಂತೆ observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ.

2. ಸಾಕ್ಷ್ಯವನ್ನು ನೀತಿಯಿಂದ ಬೇರ್ಪಡಿಸಿ

ನೀವು ಏನು ಮಾಡಲು ತೀರ್ಮಾನಿಸುತ್ತೀರಿ ಎಂಬುದರಿಂದ independently, ಸಾಕ್ಷ್ಯವು ಹೇಳುವುದನ್ನು verified, declared, inferred ಅಥವಾ unknown ಎಂದು ದಾಖಲಿಸಿ. ಅದು policies ಅನ್ನು ಓದಲು ಸುಲಭವಾಗಿರಿಸುತ್ತದೆ ಮತ್ತು instrumenting ಅನ್ನು ಮರುಮಾಡದೇ ಅವುಗಳನ್ನು ಕಠಿಣಗೊಳಿಸಲು ಅಥವಾ ಸಡಿಲಗೊಳಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. evidence basis entry ನಾಲ್ಕು ಮಟ್ಟಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

3. verified agents ಗಳಿಗೆ ಉತ್ತಮ ಮಾರ್ಗ ನೀಡಿ

ಅದು ಸೂಕ್ತವಾಗಿರುವ ಕಡೆ, ಜನರಿಗೆ ನಿರ್ಮಿಸಲಾದ pages ಬದಲಾಗಿ verified agents ಗಳಿಗೆ structured content ಅಥವಾ agent-friendly flow ಅನ್ನು ಒದಗಿಸಿ. serving AI agents structured content ಕುರಿತ guide ಪ್ಯಾಟರ್ನ್ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

4. authorization ಅನ್ನು ನಿಮ್ಮ code ನಲ್ಲೇ ಇಟ್ಟುಕೊಳ್ಳಿ

ಯಾರು ಕೇಳುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು signature ಬಳಸಿ. ಅವರಿಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ನಿಮ್ಮ ಈಗಿನ permissions, scopes ಮತ್ತು confirmations ಗಳನ್ನು ಬಳಸಿ. ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ actions ಗೆ ಇನ್ನೂ human confirmation ಅಗತ್ಯವಿರಬಹುದು, ವಿನಂತಿಗೆ ಯಾರು ಸಹಿ ಹಾಕಿದರೂ. protecting sensitive actions without blocking agents ನೋಡಿ.

5. ಸಹಿಯಿಲ್ಲದ ಮತ್ತು Unknown traffic ಗೆ ಯೋಜಿಸಿ

ಕೈಗುಣಿಸುವ support agents ಮತ್ತು tools ಗಳಲ್ಲಿ ಬದಲಾಗುವುದರಿಂದ, ಕೆಲವು ಕಾಲ signed ಮತ್ತು unsigned ವಿನಂತಿಗಳ ಮಿಶ್ರಣವನ್ನು ನಿರೀಕ್ಷಿಸಿ. ಒಂದೇ site-wide ನಿಯಮದ ಬದಲು ಪ್ರತಿ route ಗೆ declared, inferred ಮತ್ತು Unknown traffic ಗೆ ಏನಾಗಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ. handling Unknown traffic ಕುರಿತ guide ಇದನ್ನು ವಿವರಿಸುತ್ತದೆ.

Proof of Actor Web Bot Auth ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ

Proof of Actor ನಿಮ್ಮ application ಗೆ ಪ್ರತಿ interaction ನಲ್ಲಿ ಯಾರು ಅಥವಾ ಏನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ, Human, Human + AI, Agent ಅಥವಾ Unknown, ಮತ್ತು ಸಾಕ್ಷ್ಯದ ಆಧಾರವನ್ನು ತಿಳಿಸುತ್ತದೆ. Web Bot Auth signatures ಇದರ ಅತ್ಯಂತ ಬಲವಾದ ಸಾಕ್ಷ್ಯದ ಮೂಲಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ಒಂದು agent HTTP Message Signatures ಬಳಸಿ ತನ್ನ request ಗೆ ಸಹಿ ಹಾಕಿದಾಗ, Proof of Actor operator ನ ಪ್ರಕಟಿತ key ಗೆ ವಿರುದ್ಧವಾಗಿ signature ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದರೆ, ಫಲಿತಾಂಶವು ನೀವು ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಾಕ್ಷ್ಯದ ಜೊತೆಗೆ verified basis ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಒಂದು client header ನಲ್ಲಿ ತನ್ನನ್ನು ತಾನೇ ಮಾತ್ರ ಹೆಸರಿಸಿದರೆ, ಫಲಿತಾಂಶವು declared ಆಗಿರುತ್ತದೆ. ನಿರ್ಣಯವು behavioral ಅಥವಾ contextual signals ಗಳ ಮೇಲೆ ಆಧಾರಿತವಾಗಿದ್ದರೆ, ಅದನ್ನು inferred ಎಂದು ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಸಾಕ್ಷ್ಯ ಸಾಕಾಗದಿದ್ದರೆ, ಫಲಿತಾಂಶವು Unknown ಆಗಿರುತ್ತದೆ.

ನಿಮ್ಮ application ಆ ಸಂದರ್ಭದೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Policies ಗಳನ್ನು ಪ್ರತಿ route, ಪ್ರತಿ actor class ಮತ್ತು ಪ್ರತಿ basis ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, allow, adapt, challenge, review ಮತ್ತು rate-limit ಮುಂತಾದ outcomes ಗಳೊಂದಿಗೆ. ಏನೂ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ enforced ಆಗುವುದಿಲ್ಲ: ನೀವು real traffic ವಿರುದ್ಧ policy ಅನ್ನು preview ಮಾಡಿ, ನಂತರ ನಿಮ್ಮ code ನಲ್ಲಿ route by route enforce ಮಾಡುತ್ತೀರಿ.

Founding teams ಗಳು Node.js middleware, Next.js, edge integration, approved pages ಗಳ ಮೇಲಿನ browser collector, generic HTTP API, ಅಥವಾ MCP server integration ಮೂಲಕ ಸಾಕ್ಷ್ಯ ಸಂಗ್ರಹಿಸಬಹುದು. integrations ಮತ್ತು verifying signed agent requests ಕುರಿತ guide ನಲ್ಲಿದೆ ಪ್ರಾಯೋಗಿಕ ಹಂತಗಳು.

Proof of Actor standard ನಂತೆ ಅದೇ ಮಿತಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ: verified signature ಒಂದು request ಗೆ ಯಾವ key ಸಹಿ ಹಾಕಿತು ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ agent ಗೆ authorization ಇದೆಯೇ ಎಂದು ಅಲ್ಲ. Authorization ನಿಮ್ಮಲ್ಲೇ ಇರುತ್ತದೆ. evidence and limits page ಪ್ರತಿ ಫಲಿತಾಂಶ ಏನು ಬೆಂಬಲಿಸಬಹುದು ಮತ್ತು ಏನು ಬೆಂಬಲಿಸಲಾರದು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.

ಪ್ರಾರಂಭಿಸಿ

Proof of Actor private beta ನಲ್ಲಿ ಇದೆ. ಆಯ್ಕೆಯಾದ founding developer ತಂಡಗಳಿಗೆ ಒಪ್ಪಿಕೊಂಡ ಬಳಕೆ ಮಿತಿಗಳ ಒಳಗೆ automatic billing ಇಲ್ಲದೆ 12 months ವರೆಗೆ ಉಚಿತ ಪ್ರವೇಶ ಸಿಗಬಹುದು. early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ ಮತ್ತು ಯಾವ routes ಗೆ signed agents ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅವರೊಂದಿಗೆ ನೀವು ಏನು ಮಾಡಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಮಗೆ ತಿಳಿಸಿ.

DEVELOPERS ಗಾಗಿ

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: ಫಲಿತಾಂಶದ ಹಿಂದೆ ಇರುವ signals, ಇದರಿಂದ ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಕಾರಣ ಕಾಣುತ್ತದೆ.

observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ: ನಿಮ್ಮ logs ಗಳ ಪಕ್ಕದಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ನೀವು ಒಂದು policy ಆಯ್ಕೆ ಮಾಡುವವರೆಗೆ ಏನನ್ನೂ ಬದಲಾಯಿಸಬೇಡಿ. Node.js ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

ಪದೇಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

Web Bot Auth ಏನು?

Web Bot Auth ಎಂಬುದು IETF working group, webbotauth, ಮತ್ತು ಅದು ಮಾನಕೀಕರಿಸುತ್ತಿರುವ ವಿಧಾನಕ್ಕೆ ಇರುವ ಹೆಸರು: automated clients ಗಳು HTTP Message Signatures (RFC 9421) ಮೂಲಕ HTTP ವಿನಂತಿಗಳಿಗೆ ಸಹಿ ಹಾಕುತ್ತವೆ ಮತ್ತು ತಮ್ಮ public keys ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತವೆ, ಇದರಿಂದ websites ಯಾವ operator ಒಂದು ವಿನಂತಿ ಕಳುಹಿಸಿತು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

Web Bot Auth ಪೂರ್ಣಗೊಂಡ standard ಆಗಿದೆಯೇ?

ಇನ್ನೂ ಅಲ್ಲ. November 2026 ರ ವೇಳೆಗೆ, ಮುಖ್ಯ protocol document draft-ietf-webbotauth-httpsig-protocol ಕೆಲಸ ಗುಂಪಿನ Internet-Draft ಆಗಿದ್ದು revision 01 ನಲ್ಲಿ ಇದೆ. ಅದು ಆಧಾರವಾಗಿರುವ signature format RFC 9421 ಪ್ರಕಟಿತ Proposed Standard ಆಗಿದೆ.

ಮಾನ್ಯ Web Bot Auth ಸಹಿ ಇದ್ದರೆ agent ಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಮತಿ ಇದೆ ಎಂದರ್ಥವೇ?

ಇಲ್ಲ. ಅದು ಯಾವ ಕೀ ವಿನಂತಿಗೆ ಸಹಿ ಹಾಕಿತು ಮತ್ತು ಸಹಿಯಾದ ಭಾಗಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಲಿಲ್ಲ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆ agent data ಓದಬಹುದೇ, form ಸಲ್ಲಿಸಬಹುದೇ, ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದೇ ಎಂಬುದು ನಿಮ್ಮ application ಇನ್ನೂ ತೆಗೆದುಕೊಳ್ಳುವ authorization ನಿರ್ಧಾರವಾಗಿದೆ.

ಉತ್ಪನ್ನ ತಂಡಗಳು Web Bot Auth ಅನ್ನು ತಾವೇ implement ಮಾಡಬೇಕೇ?

Sites ಸಹಿಗಳನ್ನು verify ಮಾಡುತ್ತವೆ; ಅವು ತಾವು automated clients ಅನ್ನು ಸಹ ಬಳಸದೆ ಇದ್ದರೆ ಏನನ್ನೂ sign ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. Verification ನಲ್ಲಿ key directories ಅನ್ನು ಪಡೆದು, ಅವನ್ನು ಸುರಕ್ಷಿತವಾಗಿ cache ಮಾಡಿ ಮತ್ತು ಸಹಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಸೇರಿದೆ, ಇದನ್ನು Proof of Actor ನಂತಹ tool ನಿಮ್ಮಿಗಾಗಿ ಮಾಡಬಹುದು.

ತಮ್ಮ ವಿನಂತಿಗಳಿಗೆ ಸಹಿ ಹಾಕದ agents ಗಳನ್ನು ನಾವು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕು?

ಲಭ್ಯವಿರುವ ಸಾಕ್ಷ್ಯದ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸಿ: declared, inferred ಅಥವಾ Unknown. ಕೆಲವು ಕಾಲ signed ಮತ್ತು unsigned traffic ಎರಡರ ಮಿಶ್ರಣವನ್ನು ನಿರೀಕ್ಷಿಸಿ, ಮತ್ತು ಒಂದೇ site-wide ನಿಯಮದ ಬದಲು ಪ್ರತಿ route ಗೆ fallback ಅನ್ನು ಹೊಂದಿಸಿ.

Proof of Actor Web Bot Auth ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ?

ಇದು HTTP Message Signatures ಅನ್ನು ಪ್ರಕಟಿತ key ಗೆ ವಿರುದ್ಧವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದರೆ ಫಲಿತಾಂಶವನ್ನು verified basis ಜೊತೆಗೆ ವರದಿ ಮಾಡುತ್ತದೆ. ನಂತರ ನಿಮ್ಮ policies verified agents ಗಳನ್ನು declared ಅಥವಾ Unknown traffic ಗಿಂತ ಭಿನ್ನವಾಗಿ ನೋಡಬಹುದು.

ನಿಮ್ಮ app ಅನ್ನು ಯಾರು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

founding developers ನ ಸಣ್ಣ ಗುಂಪಿಗಾಗಿ private beta.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಮೌಲ್ಯವನ್ನು ವೀಕ್ಷಿಸಿ

ಮೊದಲು ಮಾತನಾಡಲು ಇಷ್ಟವಿದೆಯೆ? ಸ್ಥಾಪಕರೊಂದಿಗೆ ಮಾತನಾಡಿ