HTTP Message Signatures (RFC 9421)

HTTP Message Signatures কি

HTTP Message Signatures RFC 9421-ত সংজ্ঞায়িত, যি HTTP request বা response-ৰ অংশসমূহৰ ওপৰত digital signature সৃষ্টি আৰু যাচাই কৰাৰ বাবে এটা IETF standard। client-এ কোন components cover কৰিব সেইটো বাছি লয় (উদাহৰণস্বৰূপে method, target URI, authority আৰু selected headers), সেইবোৰৰ পৰা এটা canonical signature base তৈয়াৰ কৰে, আৰু private key-ৰে সেইটো sign কৰে। ফলাফল দুটা header-ত যায়: 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-ৰ বাবে কিয় গুৰুত্বপূর্ণ

বেছিভাগ automated traffic-এ user-agent string বা নিজে বাছি লোৱা client name-ৰে নিজকে চিনাকি দিয়ে। দুয়োটাই সহজে নকল কৰিব পাৰি। message signature বেলেগ: ই request-টোক এটা key-ৰ সৈতে সংযুক্ত কৰে, আৰু কেৱল private key-ৰ holder-এহে valid signature সৃষ্টি কৰিব পাৰে। crawlers, assistants আৰু autonomous agents-ৰ পৰা traffic গ্ৰহণ কৰা application-ৰ বাবে, ইয়াৰ অৰ্থ হয় "এই client-এ কয় যে ই X"-ৰ পৰা "এই request-টো X-এ প্ৰকাশ কৰা key-ৰে sign কৰা হৈছিল"।

এই পাৰ্থক্যই cooperative automated clients-সমূহক anonymous traffic-ৰ পৰিৱৰ্তে known participant হিচাপে ব্যৱহাৰ কৰাৰ ভিত্তি গঠন কৰে। ই এটা API-এ signed crawler-টোক structured endpoint-লৈ route কৰিবলৈ, known operator-ৰ বাবে পৃথক rate limit প্রয়োগ কৰিবলৈ, বা এটা MCP server-ক এটা tool কল কৰা ব্যক্তি/উৎসৰ বিষয়ে অধিক context দিবলৈ সহায় কৰে।

Verification বাস্তৱত কেনেকৈ কাম কৰে

1. Signature-Input আৰু Signature parse কৰক আৰু expected components cover কৰা হৈছে নে নাই নিশ্চিত কৰক। কোনো useful বস্তু cover নকৰা signature-এ সামান্যই প্রমাণ কৰে।
2. stale বা replay কৰা request-সমূহ আপোনাৰ tolerance-ৰ ভিতৰত reject কৰিবলৈ created আৰু expires parameters পৰীক্ষা কৰক (signature replay-ৰ বিষয়ে Section 7.2.2 চাওক)।
3. keyid-ক আপুনি বিশ্বাস কৰা উৎসৰ public key-লৈ resolve কৰক, যেনে operator-এ known location-ত প্ৰকাশ কৰা key directory। automated clients-ৰ বাবে IETF Web Bot Auth protocol draft-এ এনে এটা directory সংজ্ঞায়িত কৰে।
4. নিৰ্দিষ্ট কৰা ধৰণে signature base একেবাৰে পুনৰ নিৰ্মাণ কৰক আৰু declared algorithm-ৰে verify কৰক।
5. কি verified হ’ল আৰু কোন context-ত হ’ল সেইটো record কৰক, যাতে পিছৰ সিদ্ধান্তসমূহে সেইটো reference কৰিব পাৰে।

production-ত hand-rolled parsing-ৰ পৰিৱৰ্তে maintained RFC 9421 implementation ব্যৱহাৰ কৰক: canonicalization details ভুল কৰা সহজ। how to verify signed AI agent requests-ৰ guide-টোৱে code-সহ প্রতিটো step দেখুৱায়।

এটা valid signature কি প্রমাণ কৰে আৰু কি নকৰে

এটা valid signature-এ প্রমাণ কৰে যে request-টো এটা key-ৰে sign কৰা হৈছিল, আৰু, যদি key-টো এটা domain-ৰ অধীনত প্ৰকাশিত হয়, request-টো সেই domain-ৰ operator-ৰ সৈতে সম্পর্কিত। ই প্রমাণ নকৰে:

• operator-টো honest বা action-টো safe বুলি,
• কোনো ব্যক্তিয়ে request-টো নির্দেশ বা অনুমোদন কৰিছিল বুলি (delegated authority চাওক),
• client-টোকে যি কৰিবলৈ কৈছে সেইটো কৰিবলৈ অনুমতি আছে বুলি (agent authorization চাওক)।

identity evidence আৰু permission পৃথক প্রশ্ন। আপোনাৰ application-ৰ নিজৰ authentication আৰু authorization-এ এতিয়াও সিদ্ধান্ত লয় client-এ কি কৰিব পাৰে। what signed AI agent requests prove, and what they don't-সম্পর্কীয় আমাৰ blog post-এ এই বিষয়ে অধিক বিস্তাৰে আলোচনা কৰিছে।

সাধাৰণ ভুল ধাৰণা

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

Proof of Actor-এ signatures-ৰ সৈতে কেনেকৈ কাম কৰে

Proof of Actor-ত, প্ৰকাশিত key-ৰ সৈতে valid হোৱা signature-টো verified basis-ৰে record কৰা হয়, আৰু check-এ যিটো establish কৰিছে ঠিক সেইটোৱে scope কৰা হয়: key আৰু তাৰ অন্তৰ্গত identifier। উৎপন্ন হোৱা class (সাধাৰণতে Agent) কেতিয়াও authorization imply নকৰে। ফলাফলসমূহ analysis-ৰ বাবে Understand-লৈ আৰু Route-লৈ যায়, য'ত আপোনাৰ নিজৰ policies-এ সিদ্ধান্ত লয় signed client-এ structured path পাব নে, অন্য limit পাব নে, বা একেবাৰে কোনো পৰিৱৰ্তন নোহোৱাকৈ থাকিব নে। Web Bot Auth-ৰ দৰে signed-agent standard-সমূহ বিকাশমান, আৰু Proof of Actor এনে signed request-সমূহ maturity লাভ কৰাৰ লগে লগে verify কৰিবলৈ ডিজাইন কৰা হৈছে।

what the evidence can establish-সম্পর্কে অধিক পঢ়ক, বা apply for early access কৰক।

Sources

• RFC 9421: HTTP Message Signatures: signature components, parameters আৰু verification সংজ্ঞায়িত কৰা IETF standard
• RFC 9651: Structured Field Values for HTTP: Signature-Input আৰু Signature-ৰ syntax
• draft-ietf-webbotauth-httpsig-protocol: automated clients-লৈ RFC 9421 প্রয়োগ কৰা IETF Web Bot Auth draft (November 2026-ৰ মতে work in progress)