Web Bot Auth

Web Bot Auth ਕੀ ਹੈ

Web Bot Auth IETF ਵਰਕਿੰਗ ਗਰੁੱਪ ਅਤੇ ਆਟੋਮੇਟਿਡ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਇਸਦੇ Internet-Draft ਕੰਮ ਦਾ ਨਾਮ ਹੈ। ਵਿਚਾਰ ਸਿੱਧਾ ਹੈ: ਕਰਾਲਰ, AI ਸਹਾਇਕ ਅਤੇ ਖੁਦਮੁਖਤਿਆਰ ਏਜੰਟ ਆਪਣੀਆਂ HTTP ਬੇਨਤੀਆਂ ਨੂੰ HTTP Message Signatures (RFC 9421) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਈਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਪਬਲਿਕ ਕੀਜ਼ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਹਸਤਾਖਰਾਂ ਦੀ ਤਸਦੀਕ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ ਅਜਿਹੇ ਪਹਿਚਾਣਕਰਤਾ ਹੇਠ ਜੋ ਉਹ ਖੁਦ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ। ਫਿਰ ਕੋਈ ਵੈੱਬਸਾਈਟ ਇਹ ਪੱਕਾ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਸੱਚਮੁੱਚ ਉਸ ਓਪਰੇਟਰ ਵੱਲੋਂ ਆਈ ਸੀ ਜਿਸਦਾ ਨਾਮ ਉਹ ਦਿੰਦੀ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਵੀ ਦੁਆਰਾ ਕਾਪੀ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ user-agent string 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ। ਇਸਦਾ ਕਿਸੇ ਪ੍ਰੋਡਕਟ ਟੀਮ ਲਈ ਕੀ ਅਰਥ ਹੈ, ਇਸ ਲਈ Web Bot Auth for product teams ਵੇਖੋ; ਲਾਗੂ ਕਰਨ ਦੇ ਕਦਮਾਂ ਲਈ ਸਾਈਨ ਕੀਤੀਆਂ AI agent ਬੇਨਤੀਆਂ ਦੀ ਤਸਦੀਕ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਵਾਲੀ ਗਾਈਡ ਵੇਖੋ।

November 2026 ਤੱਕ, ਵਰਕਿੰਗ ਗਰੁੱਪ ਦਾ ਮੁੱਖ ਦਸਤਾਵੇਜ਼ draft-ietf-webbotauth-httpsig-protocol ਹੈ, ਜੋ in-band key discovery ਲਈ ਇੱਕ Signature-Agent header, JSON Web Key Sets 'ਤੇ ਅਧਾਰਿਤ ਇੱਕ key directory format, ਅਤੇ ਇੱਕ well-known URI ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਉਹ directory ਸਰਵ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। working group documents page ਇਸ ਨੂੰ ਸਬੰਧਿਤ individual drafts ਨਾਲ ਇਕੱਠੇ ਦਰਸਾਉਂਦਾ ਹੈ। ਇਹ Internet-Drafts ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਕੰਮ ਚੱਲ ਰਿਹਾ ਹੈ। ਚੀਜ਼ਾਂ ਜਿਵੇਂ ਕਿ keys ਕਿਵੇਂ ਖੋਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਕਿਹੜੇ request components 'ਤੇ signature ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ headers operator ਜਾਣਕਾਰੀ ਰੱਖਦੇ ਹਨ, ਸੰਸਕਰਣਾਂ ਦੇ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦੇ ਹਨ। ਲਾਗੂ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਕਿਸੇ ਵੀ snapshot ਦੀ ਬਜਾਇ ਮੌਜੂਦਾ drafts ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਵੈੱਬਸਾਈਟਾਂ ਅਤੇ APIs ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਬੋਟਾਂ ਦੀ ਪਛਾਣ user-agent strings ਅਤੇ IP ranges ਨਾਲ ਕਰਦੀਆਂ ਆ ਰਹੀਆਂ ਹਨ। ਦੋਵਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ: user-agent strings ਆਸਾਨੀ ਨਾਲ ਨਕਲੀ ਬਣਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਵੇਖੋ user-agent spoofing), ਅਤੇ IP ranges ਬਦਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ cloud providers ਵਿੱਚ ਸਾਂਝੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜਿਵੇਂ AI agents ਲੋਕਾਂ ਦੀ ਥਾਂ 'ਤੇ browse ਕਰਨ, APIs ਕਾਲ ਕਰਨ ਅਤੇ MCP servers ਵਰਤਣ ਲੱਗਦੇ ਹਨ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਹਿਯੋਗੀ ਆਟੋਮੇਟਿਡ ਕਲਾਇੰਟਾਂ ਨੂੰ ਗੁਮਨਾਮ ਕਲਾਇੰਟਾਂ ਤੋਂ ਵੱਖ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਮਜ਼ਬੂਤ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।

ਸਾਈਨ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਇਹ ਹੋਰ ਮਜ਼ਬੂਤ ਅਧਾਰ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ verified signature ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਓਪਰੇਟਰ ਨੂੰ ਲਗਾਤਾਰ ਪਛਾਣਣ, ਉਸਨੂੰ ਮਨੁੱਖ-ਸਮਾਨ ਇੰਟਰਫੇਸ ਦੀ ਬਜਾਇ ਇੱਕ ਸੰਰਚਿਤ ਮਾਰਗ ਦੇਣ, ਅਤੇ ਉਸਦੀ ਗਤੀਵਿਧੀ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਮਾਪਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

ਇਹ ਉੱਚ ਪੱਧਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

1. ਓਪਰੇਟਰ ਇੱਕ key pair ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ public key ਨੂੰ ਆਪਣੀ ਪਛਾਣ ਨਾਲ ਜੁੜੀ ਥਾਂ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੇ ਡੋਮੇਨ ਹੇਠ http-message-signatures-directory well-known path 'ਤੇ।
2. ਹਰ ਬੇਨਤੀ ਵਿੱਚ Signature-Input ਅਤੇ Signature headers ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਚੁਣੇ ਹੋਏ request components ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਨਾਲ ਹੀ ਇੱਕ key identifier, ਅਤੇ ਇੱਕ Signature-Agent header ਜੋ key directory ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
3. ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸਾਈਟ ਓਪਰੇਟਰ ਦੀਆਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਜ਼ ਲਿਆਉਂਦੀ ਜਾਂ cache ਕਰਦੀ ਹੈ, signature base ਨੂੰ ਮੁੜ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ signature ਦੀ ਤਸਦੀਕ ਕਰਦੀ ਹੈ।
4. ਸਫਲਤਾ 'ਤੇ, ਸਾਈਟ ਜਾਣਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਉਸ key ਦੇ ਧਾਰਕ ਵੱਲੋਂ ਬਣਾਈ ਗਈ ਸੀ, ਜੋ ਉਸ ਪ੍ਰਕਾਸ਼ਿਤ ਪਹਿਚਾਣਕਰਤਾ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ।

ਇਹ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ

ਇੱਕ Web Bot Auth signature ਆਟੋਮੇਟਿਡ ਕਲਾਇੰਟ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ। ਇਹ ਇਹ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ:

• ਕੀ ਓਪਰੇਟਰ ਨੂੰ ਉਹ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜੋ ਉਹ ਮੰਗ ਰਿਹਾ ਹੈ (agent authorization),
• ਕੀ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਉਸ ਕਾਰਵਾਈ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਜਾਂ ਮਨਜ਼ੂਰ ਕੀਤਾ (delegated authority),
• ਕੀ ਕਾਰਵਾਈ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਵਾਪਸ ਮਿਲਿਆ ਸਮੱਗਰੀ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤੀ ਜਾਵੇਗੀ।

ਇਹ ਅਜੇ ਵੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ authentication, authorization ਅਤੇ policy ਦੇ ਫੈਸਲੇ ਹਨ। ਸਾਡੇ ਬਲੌਗ ਪੋਸਟ signed AI agent requests ਕੀ ਸਾਬਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੀ ਨਹੀਂ ਇਸ ਸੀਮਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।

ਆਮ ਗਲਤਫ਼ਹਿਮੀਆਂ

• "ਹਰ ਬੋਟ ਜਲਦੀ ਹੀ sign ਕਰੇਗਾ।" Adoption ਕਲਾਇੰਟ ਦਰ ਕਲਾਇੰਟ ਵਧਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲੰਮੇ ਸਮੇਂ ਤੱਕ signed, declared ਅਤੇ anonymous traffic ਦਾ ਮਿਸ਼ਰਣ ਮਿਲੇਗਾ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਹਰ ਇੱਕ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।
• "ਇੱਕ signature ਬੋਟ ਨੂੰ ਚੰਗਾ ਬਣਾ ਦਿੰਦੀ ਹੈ।" ਇਹ ਬੋਟ ਨੂੰ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਬਣਾਉਂਦੀ ਹੈ। ਜਾਣਿਆ ਹੋਣਾ ਇੱਕ policy ਲਈ ਸ਼ੁਰੂਆਤ ਹੈ, policy ਖੁਦ ਨਹੀਂ।
• "Draft ਅੰਤਿਮ ਹੈ।" ਇਹ ਇੱਕ ਵਿਕਸਿਤ ਹੁੰਦਾ Internet-Draft ਹੈ। ਮੌਜੂਦਾ text ਦੇ ਅਧਾਰ 'ਤੇ ਬਣਾਓ ਅਤੇ ਸੰਸ਼ੋਧਨਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ।

Proof of Actor ਨਾਲ ਇਸਦਾ ਸੰਬੰਧ

Proof of Actor ਇੱਕ validated signature ਨੂੰ verified basis ਵਾਲੇ ਸਬੂਤ ਵਜੋਂ ਵੇਖਦਾ ਹੈ, ਜੋ ਉਸ key ਅਤੇ identifier ਤੱਕ ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਇਹ ਤਸਦੀਕ ਕਰਦਾ ਹੈ। ਇਹ ਇਸਨੂੰ declared ਨਾਮਾਂ ਅਤੇ inferred signals ਤੋਂ ਵੱਖ ਰੱਖਦਾ ਹੈ, ਅਤੇ identity ਨੂੰ ਇਜਾਜ਼ਤ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ। Proof of Actor ਨੂੰ ਮਿਆਰਾਂ ਦੇ ਵਿਕਸਿਤ ਹੋਣ ਨਾਲ signed requests ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ; Route ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ policies ਨਿਰਣੇ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇੱਕ verified agent ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

ਦੇਖੋ ਇਹ APIs ਅਤੇ MCP servers ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਜਾਂ early access ਲਈ ਅਰਜ਼ੀ ਦਿਓ।

ਸਰੋਤ

• IETF Web Bot Auth ਵਰਕਿੰਗ ਗਰੁੱਪ: charter, chairs ਅਤੇ status
• Web Bot Auth ਵਰਕਿੰਗ ਗਰੁੱਪ ਦਸਤਾਵੇਜ਼: ਮੌਜੂਦਾ working group ਅਤੇ ਸਬੰਧਿਤ drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, JWKS key directory ਅਤੇ ਇਸਦਾ well-known URI (November 2026 ਤੱਕ ਕੰਮ ਚੱਲ ਰਿਹਾ ਹੈ)
• RFC 9421: HTTP Message Signatures: signature standard ਜਿਸ 'ਤੇ Web Bot Auth ਨਿਰਭਰ ਕਰਦਾ ਹੈ