HTTP Message Signatures (RFC 9421)

HTTP Message Signatures কী

HTTP Message Signatures সংজ্ঞায়িত হয়েছে RFC 9421-এ, যা একটি IETF standard - HTTP request বা response-এর অংশগুলির উপর digital signature তৈরি এবং যাচাই করার জন্য। একটি client কোন component গুলো cover করা হবে তা বেছে নেয় (উদাহরণস্বরূপ method, target URI, authority এবং selected headers), সেগুলো থেকে একটি canonical signature base তৈরি করে, এবং private key দিয়ে সেটিতে signature করে। ফলাফল দুটি header-এ যায়: Signature-Input (Section 4.1), যেখানে covered component এবং created, expires, keyid ও alg-এর মতো parameter তালিকাভুক্ত থাকে, এবং Signature (Section 4.2), যেখানে signature value নিজেই বহন করা হয়। উভয়ই RFC 9651-এর Structured Field Values syntax ব্যবহার করে।

Receiver request থেকে যে অংশটি আসলে পেয়েছে, সেখান থেকে একই signature base (Section 2.5) পুনর্গঠন করে, keyid দ্বারা উল্লেখিত public key খুঁজে বের করে, এবং signature যাচাই করে। Signature দ্বারা covered কোনো কিছু transit-এর সময় বদলে গেলে verification ব্যর্থ হয়।

Apps, APIs and MCP servers-এর জন্য কেন এটি গুরুত্বপূর্ণ

বেশিরভাগ automated traffic নিজেকে user-agent string বা client-এর নিজস্ব নাম দিয়ে পরিচয় করায়। দুটিই সহজে নকল করা যায়। Message signature আলাদা: এটি request-কে একটি key-এর সাথে যুক্ত করে, এবং কেবল private key-এর holder-ই একটি valid signature তৈরি করতে পারে। Crawlers, assistants এবং autonomous agents থেকে traffic গ্রহণকারী একটি application-এর ক্ষেত্রে, এটি "এই client বলছে এটি X" থেকে "এই request X প্রকাশিত key দিয়ে signed" - এই পর্যায়ে নিয়ে যায়।

এই পার্থক্য সহযোগী automated client-দের anonymous traffic না ভেবে known participant হিসেবে বিবেচনার ভিত্তি তৈরি করে। এটি API-কে একটি signed crawler-কে structured endpoint-এ route করতে, known operator-এর জন্য ভিন্ন rate limit প্রয়োগ করতে, অথবা একটি MCP server-কে কে tool কল করছে সে বিষয়ে আরও context দিতে সাহায্য করে।

বাস্তবে verification কীভাবে কাজ করে

1. Signature-Input এবং Signature parse করুন এবং প্রত্যাশিত component গুলো covered আছে কি না নিশ্চিত করুন। যে signature কোনো দরকারি বিষয় cover করে না, তা খুব কমই প্রমাণ দেয়।
2. created এবং expires parameter পরীক্ষা করে আপনার tolerance-এর মধ্যে stale বা replayed request reject করুন (signature replay সম্পর্কে Section 7.2.2 দেখুন)।
3. keyid-কে এমন একটি source থেকে public key-তে resolve করুন, যেটি আপনি trust করেন, যেমন operator যে key directory একটি পরিচিত location-এ প্রকাশ করে। IETF-এর Web Bot Auth protocol draft automated client-দের জন্য এ ধরনের একটি directory সংজ্ঞায়িত করে।
4. নির্ধারিত মতো signature base ঠিক সেইভাবে পুনর্গঠন করুন এবং declared algorithm দিয়ে তা যাচাই করুন।
5. কী verified হয়েছে এবং কোন context-এ হয়েছে তা record করুন, যাতে পরবর্তী decision-গুলো সেটি reference করতে পারে।

Production-এ হাতে লেখা parsing-এর বদলে maintained RFC 9421 implementation ব্যবহার করুন: canonicalization-এর details ভুল করা সহজ। signed AI agent request কীভাবে verify করতে হয় গাইডটি code সহ প্রতিটি ধাপ দেখায়।

একটি valid signature কী প্রমাণ করে এবং কী করে না

একটি valid signature প্রমাণ করে যে request-টি একটি key দিয়ে signed হয়েছে, এবং key যদি একটি domain-এর অধীনে প্রকাশিত হয়, তবে request-টি সেই domain-এর operator-এর সাথে সম্পর্কিত। এটি প্রমাণ করে না:

• operator সৎ বা action নিরাপদ,
• কোনো person request-টি নির্দেশ দিয়েছে বা অনুমোদন করেছে কিনা (দেখুন delegated authority),
• client যা চাইছে তা করার অনুমতি তার আছে কিনা (দেখুন agent authorization).

Identity evidence এবং permission আলাদা প্রশ্ন। আপনার application-এর নিজস্ব authentication এবং authorization এখনও নির্ধারণ করে client কী করতে পারে। আমাদের blog post signed AI agent request কী প্রমাণ করে, এবং কী করে না এই বিষয়টি আরও বিস্তারিতভাবে ব্যাখ্যা করে।

প্রচলিত ভুল ধারণা

• "Signed মানে trusted." Signed মানে attribution করা যায়। Trust হলো আপনি attributed party সম্পর্কে যে policy decision নেন।
• "Signature API keys-এর বিকল্প." এগুলো ভিন্ন প্রশ্নের উত্তর দেয়। API key বলে কোন account কল করছে; signature বলে কোন client request তৈরি করেছে। অনেক deployment-এ দুটোই উপকারী।
• "Unsigned traffic মানেই malicious." আজকের বেশিরভাগ automated traffic unsigned। Signature না থাকা মানে কী স্থাপন করা যাবে তা কমে যায়, এর বেশি নয়। এই কারণেই Unknown একটি first-class result।

Proof of Actor signatures-কে কীভাবে treat করে

Proof of Actor-এ, প্রকাশিত key-এর বিরুদ্ধে validate হওয়া একটি signature-কে basis verified হিসেবে record করা হয়, এবং যাচাই যা স্থাপন করেছে ঠিক সেই পর্যন্ত scope করা হয়: key এবং সেটির identifier। ফলস্বরূপ class (সাধারণত Agent) কখনও authorization নির্দেশ করে না। Result বিশ্লেষণের জন্য Understand-এ এবং Route-এ প্রবাহিত হয়, যেখানে আপনার own policies নির্ধারণ করে signed client structured path পাবে কি না, ভিন্ন limit পাবে কি না, বা কোনো change হবে না কি না। Web Bot Auth-এর মতো signed-agent standard evolve হচ্ছে, এবং Proof of Actor এমনভাবে design করা হয়েছে যাতে সেগুলো mature হওয়ার সাথে সাথে signed request verify করা যায়।

evidence কী স্থাপন করতে পারে সম্পর্কে আরও পড়ুন, অথবা early access-এর জন্য apply করুন.

Sources

• RFC 9421: HTTP Message Signatures: signature component, parameter এবং verification নির্ধারণকারী IETF standard
• RFC 9651: Structured Field Values for HTTP: Signature-Input এবং Signature-এর syntax
• draft-ietf-webbotauth-httpsig-protocol: automated client-দের জন্য RFC 9421 প্রয়োগকারী IETF Web Bot Auth draft (November 2026 অনুযায়ী work in progress)