HTTP Message Signatures (RFC 9421)

HTTP Message Signatures ਕੀ ਹਨ

HTTP Message Signatures RFC 9421 ਵਿੱਚ define ਕੀਤੇ ਗਏ ਹਨ, ਜੋ HTTP request ਜਾਂ response ਦੇ ਹਿੱਸਿਆਂ ਉੱਤੇ digital signatures ਬਣਾਉਣ ਅਤੇ verify ਕਰਨ ਲਈ ਇੱਕ IETF standard ਹੈ। ਇੱਕ client ਇਹ ਚੁਣਦਾ ਹੈ ਕਿ ਕਿਹੜੇ components cover ਕਰਨੇ ਹਨ (ਉਦਾਹਰਨ ਵਜੋਂ method, target URI, authority ਅਤੇ selected headers), ਉਨ੍ਹਾਂ ਤੋਂ ਇੱਕ canonical signature base ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ private key ਨਾਲ sign ਕਰਦਾ ਹੈ। ਨਤੀਜਾ ਦੋ headers ਵਿੱਚ ਆਉਂਦਾ ਹੈ: Signature-Input (Section 4.1), ਜੋ covered components ਅਤੇ parameters ਜਿਵੇਂ created, expires, keyid ਅਤੇ alg ਦੀ list ਕਰਦਾ ਹੈ, ਅਤੇ Signature (Section 4.2), ਜੋ signature value ਖੁਦ carry ਕਰਦਾ ਹੈ। ਦੋਵੇਂ RFC 9651 ਦੀ Structured Field Values syntax ਵਰਤਦੇ ਹਨ।

Receiver ਉਸ request ਤੋਂ, ਜੋ ਉਸਨੇ ਅਸਲ ਵਿੱਚ receive ਕੀਤੀ ਹੈ, ਉਹੀ signature base (Section 2.5) ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, keyid ਦੁਆਰਾ ਦਰਸਾਈ public key lookup ਕਰਦਾ ਹੈ, ਅਤੇ signature check ਕਰਦਾ ਹੈ। ਜੇ transit ਦੌਰਾਨ signature ਨਾਲ covered ਕੁਝ ਵੀ change ਹੋ ਗਿਆ ਹੋਵੇ, ਤਾਂ verification fail ਹੋ ਜਾਂਦੀ ਹੈ।

Apps, APIs ਅਤੇ MCP servers ਲਈ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹਨ

ਅਧਿਕਤਰ automated traffic ਆਪਣੀ ਪਛਾਣ user-agent string ਜਾਂ self-chosen client name ਨਾਲ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਨੂੰ copy ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ। Message signature ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ: ਇਹ request ਨੂੰ ਇੱਕ key ਨਾਲ tie ਕਰਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ਼ private key ਦਾ holder ਹੀ valid signature produce ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ application ਲਈ, ਜੋ crawlers, assistants ਅਤੇ autonomous agents ਤੋਂ traffic receive ਕਰ ਰਹੀ ਹੈ, ਇਹ "ਇਹ client ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ X ਹੈ" ਨੂੰ "ਇਸ request ਨੂੰ X ਵੱਲੋਂ publish ਕੀਤੀ ਗਈ key ਨੇ sign ਕੀਤਾ ਸੀ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਇਹ ਫਰਕ cooperating automated clients ਨੂੰ anonymous traffic ਦੀ ਥਾਂ known participants ਵਜੋਂ treat ਕਰਨ ਦੀ foundation ਹੈ। ਇਹ API ਨੂੰ signed crawler ਨੂੰ structured endpoint ਵੱਲ route ਕਰਨ, ਜਾਣੇ-ਪਛਾਣੇ operator ਲਈ ਵੱਖਰਾ rate limit apply ਕਰਨ, ਜਾਂ MCP server ਨੂੰ tool call ਕਰਨ ਵਾਲੇ ਬਾਰੇ ਹੋਰ context ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

Practice ਵਿੱਚ verification ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ

1. Signature-Input ਅਤੇ Signature parse ਕਰੋ ਅਤੇ confirm ਕਰੋ ਕਿ expected components cover ਕੀਤੇ ਗਏ ਹਨ। ਇੱਕ signature ਜੋ ਕੁਝ ਵੀ meaningful cover ਨਹੀਂ ਕਰਦੀ, ਥੋੜ੍ਹਾ ਹੀ ਸਾਬਤ ਕਰਦੀ ਹੈ।
2. created ਅਤੇ expires parameters check ਕਰੋ ਤਾਂ ਜੋ ਤੁਹਾਡੀ tolerance ਦੇ ਅੰਦਰ stale ਜਾਂ replay ਕੀਤੀਆਂ requests reject ਕੀਤੀਆਂ ਜਾ ਸਕਣ (signature replay ਬਾਰੇ Section 7.2.2 ਵੇਖੋ)।
3. keyid ਨੂੰ ਇੱਕ public key ਨਾਲ resolve ਕਰੋ, ਕਿਸੇ ਐਸੇ source ਤੋਂ ਜਿਸ 'ਤੇ ਤੁਸੀਂ trust ਕਰਦੇ ਹੋ, ਜਿਵੇਂ operator ਵੱਲੋਂ known location 'ਤੇ publish ਕੀਤੀ key directory। IETF ਦਾ Web Bot Auth protocol draft automated clients ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦੀ directory define ਕਰਦਾ ਹੈ।
4. Signature base ਨੂੰ exactly ਉਸੇ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਬਣਾਓ ਜਿਵੇਂ specified ਹੈ ਅਤੇ ਉਸਨੂੰ declared algorithm ਨਾਲ verify ਕਰੋ।
5. Record ਕਰੋ ਕਿ ਕੀ verify ਹੋਇਆ ਅਤੇ ਕਿਸ context ਵਿੱਚ, ਤਾਂ ਜੋ ਬਾਅਦ ਦੇ decisions ਇਸਦਾ reference ਲੈ ਸਕਣ।

Production ਵਿੱਚ, hand-rolled parsing ਦੀ ਥਾਂ maintained RFC 9421 implementation ਵਰਤੋ: canonicalization ਦੇ details ਗਲਤ ਹੋਣੇ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। how to verify signed AI agent requests ਉੱਤੇ guide code ਨਾਲ ਹਰ step ਨੂੰ walk through ਕਰਦਾ ਹੈ।

ਇੱਕ valid signature ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ request ਇੱਕ key ਨਾਲ sign ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਜੇ key ਕਿਸੇ domain ਹੇਠ publish ਕੀਤੀ ਗਈ ਹੈ, ਤਾਂ request ਉਸ domain ਦੇ operator ਨਾਲ associated ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ:

• ਕਿ operator honest ਹੈ ਜਾਂ action safe ਹੈ,
• ਕਿ ਕਿਸੇ person ਨੇ request ਨੂੰ instruct ਜਾਂ approve ਕੀਤਾ ਸੀ (ਦੇਖੋ delegated authority),
• ਕਿ client ਨੂੰ ਉਹ ਕਰਨ ਦੀ permission ਹੈ ਜੋ ਉਹ ask ਕਰ ਰਹੀ ਹੈ (ਦੇਖੋ agent authorization).

Identity evidence ਅਤੇ permission ਵੱਖਰੇ questions ਹਨ। ਤੁਹਾਡੀ application ਦੀ own authentication ਅਤੇ authorization ਹੀ ਅਜੇ ਵੀ decide ਕਰਦੀ ਹੈ ਕਿ client ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਡੀ blog post what signed AI agent requests prove, and what they don't ਇਸਨੂੰ ਹੋਰ detail ਨਾਲ cover ਕਰਦੀ ਹੈ।

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

• "Signed means trusted." Signed ਦਾ ਮਤਲਬ attributable ਹੁੰਦਾ ਹੈ। Trust ਇੱਕ policy decision ਹੈ ਜੋ ਤੁਸੀਂ attributed party ਬਾਰੇ ਕਰਦੇ ਹੋ।
• "Signatures replace API keys." ਇਹ ਵੱਖਰਾ question answer ਕਰਦੇ ਹਨ। ਇੱਕ API key ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ account call ਕਰ ਰਿਹਾ ਹੈ; ਇੱਕ signature ਦੱਸਦੀ ਹੈ ਕਿ request ਕਿਸ client ਨੇ ਬਣਾਈ। ਬਹੁਤ ਸਾਰੀਆਂ deployments ਦੋਵੇਂ ਤੋਂ benefit ਲੈਂਦੀਆਂ ਹਨ।
• "Unsigned traffic is malicious." ਅੱਜ ਜ਼ਿਆਦਾਤਰ automated traffic unsigned ਹੈ। Missing signatures ਨਾਲ ਜੋ establish ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਉਹ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਤੋਂ ਵੱਧ ਨਹੀਂ। ਇਸੇ ਲਈ Unknown ਇੱਕ first-class result ਹੈ।

Proof of Actor signatures ਨਾਲ ਕਿਵੇਂ deal ਕਰਦਾ ਹੈ

Proof of Actor ਵਿੱਚ, ਇੱਕ signature ਜੋ published key ਦੇ against validate ਹੁੰਦੀ ਹੈ, basis verified ਨਾਲ record ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਸਿਰਫ਼ ਉਸੇ ਤੱਕ scoped ਰਹਿੰਦੀ ਹੈ ਜੋ check ਨੇ establish ਕੀਤਾ: key ਅਤੇ ਉਹ identifier ਜਿਸ ਨਾਲ ਇਹ belong ਕਰਦੀ ਹੈ। resulting class (ਆਮ ਤੌਰ 'ਤੇ Agent) ਕਦੇ ਵੀ authorization imply ਨਹੀਂ ਕਰਦੀ। Results analysis ਲਈ Understand ਵਿੱਚ ਅਤੇ Route ਵਿੱਚ flow ਕਰਦੇ ਹਨ, ਜਿੱਥੇ ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ policies decide ਕਰਦੀਆਂ ਹਨ ਕਿ signed client ਨੂੰ structured path ਮਿਲੇ, ਵੱਖਰਾ limit ਮਿਲੇ, ਜਾਂ ਕੋਈ change ਨਾ ਹੋਵੇ। Web Bot Auth ਵਰਗੇ signed-agent standards evolve ਹੋ ਰਹੇ ਹਨ, ਅਤੇ Proof of Actor ਨੂੰ signed requests verify ਕਰਨ ਲਈ ਇਸ ਤਰ੍ਹਾਂ design ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਜਿਵੇਂ ਉਹ mature ਹੁੰਦੇ ਹਨ।

what the evidence can establish ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ, ਜਾਂ apply for early access ਕਰੋ।

ਸਰੋਤ

• RFC 9421: HTTP Message Signatures: IETF standard ਜੋ signature components, parameters ਅਤੇ verification define ਕਰਦਾ ਹੈ
• RFC 9651: Structured Field Values for HTTP: Signature-Input ਅਤੇ Signature ਦੀ syntax
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft ਜੋ automated clients 'ਤੇ RFC 9421 apply ਕਰਦਾ ਹੈ (November 2026 ਤੱਕ work in progress)