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 ৰে সাইন কৰে। ফলাফল দুটা 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 এ Section 2.5 ৰ অনুসৰি request যি বাস্তৱতে পালে তাৰ পৰা একেই signature base পুনর্গঠন কৰে, keyid দ্বাৰা উল্লেখিত public key খোঁজে, আৰু signature যাচাই কৰে। signature ত covered কোনো বস্তু transit ত সলনি হলে, verification ব্যর্থ হয়।

apps, APIs আৰু MCP servers ৰ বাবে কিয় ই গুরুত্বপূর্ণ

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

সেই পাৰ্থক্যই cooperating 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 কৰা হৈছে নে নিশ্চিত কৰক। কোনো উপযোগী বস্তু cover নকৰা signature এ খুব কম প্ৰমাণ দিয়ে।
2. stale বা replay কৰা request আপোনাৰ tolerance ৰ ভিতৰত ৰদ কৰিবলৈ created আৰু expires parameters পৰীক্ষা কৰক (signature replay বিষয়ে Section 7.2.2 চাওক)।
3. keyid ক আপুনি বিশ্বাস কৰা উৎসৰ পৰা public key লৈ resolve কৰক, যেনে operator এ known location ত প্ৰকাশ কৰা key directory। IETF ৰ Web Bot Auth protocol draft এ automated clients ৰ বাবে এনে directory সংজ্ঞায়িত কৰে।
4. specified ৰূপে signature base নিখুঁতভাৱে পুনর্গঠন কৰক আৰু declared algorithm ৰে যাচাই কৰক।
5. কি যাচাই কৰা হ’ল আৰু কোন context ত, সেইটো record কৰক, যাতে পিছৰ সিদ্ধান্তবোৰে তাত reference দিব পাৰে।

production ত, হাতেৰে কৰা parsing ৰ সলনি maintained RFC 9421 implementation ব্যৱহাৰ কৰক: canonicalization ৰ detail ভুল কৰা সহজ। how to verify signed AI agent requests ৰ guide এ code সহ প্ৰতিটো ধাপ দেখুৱায়।

valid signature এ ক’ণ প্ৰমাণ কৰে আৰু ক’ণ প্ৰমাণ নকৰে

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

• operator সৎ বা action টো নিৰাপদ,
• কোনো ব্যক্তি এ request খন নির্দেশ বা অনুমোদন কৰিছিল (delegated authority চাওক),
• client টো যি কৰিবলৈ কৈছে, তাৰ বাবে অনুমোদিত (agent authorization চাওক)।

identity evidence আৰু permission পৃথক প্ৰশ্ন। আপোনাৰ application ৰ own authentication আৰু authorization এহে এতিয়াও নিৰ্ধাৰণ কৰে client এ কি কৰিব পাৰে। আমাৰ what signed AI agent requests prove, and what they don't blog post এ এই বিষয়ে অধিক ব্যাখ্যা কৰে।

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

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

Proof of Actor signature ক কেনেকৈ গণ্য কৰে

Proof of Actor ত, published key ৰ বিৰুদ্ধে validate হোৱা signature ক basis verified সহ record কৰা হয়, আৰু check এ যি স্থাপন কৰিছে ঠিক তাতেই সীমাবদ্ধ থাকে: key আৰু যি identifier ৰ অন্তৰ্গত। resulting class (সাধাৰণতে Agent) কেতিয়াও authorization সূচায় নকৰে। Result সমূহ analysis ৰ বাবে Understand লৈ যায় আৰু Route লৈ যায়, য’ত আপোনাৰ নিজৰ policy এ নিৰ্ধাৰণ কৰে signed client এ structured path পাব নে, পৃথক limit পাব নে, বা একো সলনি নহ’ব। Web Bot Auth ৰ দৰে signed-agent standard সমূহ evolve হৈ আছে, আৰু Proof of Actor সেইবোৰ mature হোৱাৰ লগে লগে signed request যাচাই কৰিবলৈ design কৰা হৈছে।

evidence এ কি স্থাপন কৰিব পাৰে বিষয়ে অধিক পঢ়ক, বা 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)