ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
ಗ್ಲಾಸರಿ

HTTP Message Signatures (RFC 9421)

Toshendra Sharma

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

HTTP ಸಂದೇಶದ ಆಯ್ದ ಭಾಗಗಳಿಗೆ signature ಹಾಕಲು ಬಳಸುವ IETF standard (RFC 9421), ಇದರಿಂದ receiver ನಿರ್ದಿಷ್ಟ key ನ holder ಆ request ಅನ್ನು ಉತ್ಪಾದಿಸಿದ್ದಾನೆ ಎಂದು ಪರಿಶೀಲಿಸಬಹುದು.

HTTP Message Signatures ಎಂದರೆ ಏನು

HTTP Message Signatures ಅನ್ನು RFC 9421 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ, ಇದು HTTP request ಅಥವಾ response ನ ಭಾಗಗಳ ಮೇಲೆ digital signatures ರಚಿಸಲು ಮತ್ತು ಪರಿಶೀಲಿಸಲು ಇರುವ 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 ಮತ್ತು created, expires, keyid ಮತ್ತು alg ಮುಂತಾದ parameters ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು Signature (Section 4.2), ಇದು signature value ಅನ್ನು ತಾನೇ ಹೊತ್ತಿರುತ್ತದೆ. ಎರಡೂ RFC 9651 ನ Structured Field Values syntax ಅನ್ನು ಬಳಸುತ್ತವೆ.

receiver ಅದು ನಿಜವಾಗಿ ಪಡೆದ request ನಿಂದ ಅದೇ signature base ಅನ್ನು (Section 2.5) ಮತ್ತೆ ನಿರ್ಮಿಸುತ್ತದೆ, keyid ಮೂಲಕ ಉಲ್ಲೇಖಿಸಲಾದ public key ಅನ್ನು ಹುಡುಕುತ್ತದೆ, ಮತ್ತು signature ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. signature ಯಿಂದ cover ಆಗಿರುವ ಯಾವುದಾದರೂ ವಸ್ತು transit ನಲ್ಲಿ ಬದಲಾಗಿದ್ದರೆ, verification ವಿಫಲವಾಗುತ್ತದೆ.

ಅವು apps, APIs ಮತ್ತು MCP servers ಗೆ ಏಕೆ ಮುಖ್ಯ

ಬಹುತೇಕ ಸ್ವಯಂಚಾಲಿತ traffic ತಾನು user-agent string ಅಥವಾ ಸ್ವಯಂ ಆಯ್ದ client name ಮೂಲಕ ತನ್ನನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಎರಡೂ ನಕಲಿಸಲು ತುಂಬಾ ಸುಲಭ. Message signature ಬೇರೆ: ಅದು request ಅನ್ನು ಒಂದು key ಗೆ ಜೋಡಿಸುತ್ತದೆ, ಮತ್ತು private key ಯ holder ಮಾತ್ರ ಮಾನ್ಯ signature ಅನ್ನು ರಚಿಸಬಹುದು. crawlers, assistants ಮತ್ತು autonomous agents ಗಳಿಂದ traffic ಸ್ವೀಕರಿಸುವ application ಗೆ, ಇದು "ಈ client ತಾನು X ಎಂದು ಹೇಳುತ್ತದೆ" ಎಂಬುದನ್ನು "ಈ request ಅನ್ನು X ಪ್ರಕಟಿಸುವ key sign ಮಾಡಿದೆ" ಎಂಬುದಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಆ ವ್ಯತ್ಯಾಸವು ಸಹಕರಿಸುವ automated clients ಗಳನ್ನು anonymous traffic ಬದಲು known participants ಆಗಿ ಪರಿಗಣಿಸುವ ಆಧಾರವಾಗಿದೆ. ಇದು API ಗೆ signed crawler ಅನ್ನು structured endpoint ಗೆ route ಮಾಡಲು, known operator ಗೆ ಬೇರೆ rate limit ಅನ್ವಯಿಸಲು, ಅಥವಾ MCP server ಗೆ tool ಅನ್ನು ಯಾರಿಂದ ಕರೆ ಮಾಡಲಾಗುತ್ತಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ context ನೀಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

verification ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

  1. Signature-Input ಮತ್ತು Signature ಅನ್ನು parse ಮಾಡಿ, ನಿರೀಕ್ಷಿತ components cover ಆಗಿರುವುದನ್ನು ದೃಢಪಡಿಸಿ. ಉಪಯುಕ್ತವಾದ ಯಾವುದನ್ನೂ cover ಮಾಡದ signature ಬಹಳ ಕಡಿಮೆ ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
  2. ನಿಮ್ಮ ಸಹಿಷ್ಣುತೆ ಒಳಗೆ stale ಅಥವಾ replay ಆದ requests ಅನ್ನು ತಿರಸ್ಕರಿಸಲು created ಮತ್ತು expires parameters ಅನ್ನು ಪರಿಶೀಲಿಸಿ (signature replay ಕುರಿತು Section 7.2.2 ನೋಡಿ).
  3. ನೀವು ನಂಬುವ source ನಿಂದ, ಉದಾಹರಣೆಗೆ operator ಪ್ರಕಟಿಸುವ ಮತ್ತು ತಿಳಿದಿರುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸುವ key directory ಯಿಂದ, keyid ಅನ್ನು public key ಗೆ resolve ಮಾಡಿ. IETF Web Bot Auth protocol draft automated clients ಗಾಗಿ ಅಂತಹ directory ಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
  4. ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಂತೆ signature base ಅನ್ನು ನಿಖರವಾಗಿ ಮತ್ತೆ ನಿರ್ಮಿಸಿ ಮತ್ತು declared algorithm ನೊಂದಿಗೆ ಅದನ್ನು verify ಮಾಡಿ.
  5. ಯಾವುದು verified ಆಗಿದೆ ಮತ್ತು ಯಾವ context ನಲ್ಲಿ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ, ನಂತರದ ನಿರ್ಣಯಗಳು ಅದನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದಾಗಿರಲಿ.

production ನಲ್ಲಿ, ಕೈಯಾರೆ parsing ಮಾಡುವ ಬದಲು ನಿರ್ವಹಿಸಲ್ಪಡುವ RFC 9421 implementation ಅನ್ನು ಬಳಸಿ: canonicalization ವಿವರಗಳನ್ನು ತಪ್ಪಾಗಿ ಮಾಡುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. signed AI agent requests ಅನ್ನು ಹೇಗೆ verify ಮಾಡುವುದು ಎಂಬ guide code ಸಹಿತವಾಗಿ ಪ್ರತಿ ಹಂತವನ್ನು ವಿವರಿಸುತ್ತದೆ.

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

ಮಾನ್ಯ signature ಯು request ಒಂದು key ನಿಂದ sign ಆಗಿತ್ತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಆ key ಒಂದು domain ಅಡಿಯಲ್ಲಿ ಪ್ರಕಟಿತವಾಗಿದ್ದರೆ, ಆ request ಆ domain ನ operator ಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಇದು ಕೆಳಗಿನವುಗಳನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ:

  • operator ಸತ್ಯವಂತನು ಅಥವಾ action ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂಬುದನ್ನು,
  • request ಅನ್ನು ಒಬ್ಬ person ನಿರ್ದೇಶಿಸಿದ್ದಾನೆ ಅಥವಾ approve ಮಾಡಿದ್ದಾನೆ ಎಂಬುದನ್ನು (see delegated authority),
  • client ಅದು ಕೇಳುತ್ತಿರುವ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅನುಮತಿ ಹೊಂದಿದೆ ಎಂಬುದನ್ನು (see agent authorization).

identity evidence ಮತ್ತು permission ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು. ನಿಮ್ಮ application ನ ಸ್ವಂತ authentication ಮತ್ತು authorization ಇನ್ನೂ client ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ ಎಂಬ ನಮ್ಮ blog post ಇದನ್ನು ಇನ್ನಷ್ಟು ವಿವರವಾಗಿ ಒಳಗೊಂಡಿದೆ.

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

  • "Signed ಎಂದರೆ trusted." Signed ಎಂದರೆ attributable. Trust ಎಂದರೆ ನೀವು attributed party ಕುರಿತು ತೆಗೆದುಕೊಳ್ಳುವ policy decision.
  • "Signatures API keys ಗಳನ್ನು ಬದಲಿಸುತ್ತವೆ." ಅವು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ. API key ಯಾವ account ಕರೆ ಮಾಡುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ; signature ಯಾವ client request ಅನ್ನು ಉತ್ಪಾದಿಸಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅನೇಕ deployments ಗೆ ಎರಡೂ ಉಪಯುಕ್ತ.
  • "Unsigned traffic malicious ಆಗಿದೆ." ಇಂದಿನ ಬಹುತೇಕ automated traffic unsigned ಆಗಿದೆ. Signatures ಇಲ್ಲದಿರುವುದು ಸ್ಥಾಪಿಸಬಹುದಾದ ಮಾಹಿತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಏನೂ ಅಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ Unknown ಒಂದು first-class result ಆಗಿದೆ.

Proof of Actor signatures ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ

Proof of Actor ನಲ್ಲಿ, published key ಗೆ ವಿರುದ್ಧವಾಗಿ validate ಆಗುವ signature ಅನ್ನು basis verified ಎಂದು ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪರಿಶೀಲನೆ ಸ್ಥಾಪಿಸಿದ ವಿಷಯಗಳಿಗೆ ಮಾತ್ರ ವ್ಯಾಪ್ತಿಗೊಳಿಸಲಾಗುತ್ತದೆ: key ಮತ್ತು ಅದು ಸೇರಿರುವ identifier. ಪರಿಣಾಮವಾಗಿ ಬರುವ class (ಸಾಮಾನ್ಯವಾಗಿ Agent) ಎಂದಿಗೂ authorization ಅನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ. ಫಲಿತಾಂಶಗಳು ವಿಶ್ಲೇಷಣೆಗೆ Understand ಗೆ, ಮತ್ತು Route ಗೆ ಹರಿಯುತ್ತವೆ, ಅಲ್ಲಿ ನಿಮ್ಮದೇ policies signed client ಗೆ structured path, ಬೇರೆ limit, ಅಥವಾ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲದಿರುವುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. Web Bot Auth ಮುಂತಾದ signed-agent standards ಅಭಿವೃದ್ಧಿಯಾಗುತ್ತಿವೆ, ಮತ್ತು ಅವು成熟ವಾಗುವಂತೆ signed requests ಗಳನ್ನು verify ಮಾಡಲು Proof of Actor ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

evidence ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಿ, ಅಥವಾ early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ.

ಮೂಲಗಳು

ನಿಮ್ಮ own app ನಲ್ಲಿ actor intelligence ನೋಡಿ.

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

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