HTTP Message Signatures (RFC 9421)

HTTP Message Signatures എന്താണ്

HTTP Message Signatures നിർവചിച്ചിരിക്കുന്നത് RFC 9421-ൽ ആണ്, ഇത് ഒരു HTTP അഭ്യർത്ഥനയിലോ പ്രതികരണത്തിലോ ഉള്ള ഭാഗങ്ങൾക്കുമേൽ ഡിജിറ്റൽ ഒപ്പുകൾ സൃഷ്ടിക്കുകയും സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നതിനുള്ള ഒരു IETF സ്റ്റാൻഡേർഡ് ആണ്. ഒരു ക്ലയന്റ് ഏത് ഘടകങ്ങളെയാണ് ഉൾപ്പെടുത്തേണ്ടത് എന്ന് തിരഞ്ഞെടുക്കുന്നു (ഉദാഹരണത്തിന് method, target URI, authority, തിരഞ്ഞെടുത്ത headers), അവയിൽ നിന്ന് ഒരു canonical signature base നിർമ്മിക്കുന്നു, പിന്നെ അത് ഒരു private key ഉപയോഗിച്ച് ഒപ്പിടുന്നു. ഫലം രണ്ട് headers-ലായി എത്തുന്നു: Signature-Input (Section 4.1), ഇതിൽ ഉൾപ്പെടുത്തിയ ഘടകങ്ങളും created, expires, keyid and alg പോലുള്ള parameters-ഉം പട്ടികപ്പെടുത്തുന്നു, 그리고 Signature (Section 4.2), ഇതിൽ signature value തന്നെയാണ് ഉൾപ്പെടുന്നത്. രണ്ടും RFC 9651-ന്റെ Structured Field Values syntax ഉപയോഗിക്കുന്നു.

സ്വീകരിക്കുന്നവൻ താൻ യഥാർത്ഥത്തിൽ ലഭിച്ച request-ൽ നിന്ന് അതേ signature base (Section 2.5) പുനർനിർമിക്കുന്നു, keyid-ൽ സൂചിപ്പിച്ചിരിക്കുന്ന public key കണ്ടെത്തുന്നു, പിന്നെ signature പരിശോധിക്കുന്നു. signature ഉൾപ്പെടുത്തിയ ഏതെങ്കിലും ഭാഗം transit-ൽ മാറിയാൽ verification പരാജയപ്പെടും.

apps, APIs and MCP servers-ന് ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

മിക്ക automated traffic-ഉം ഒരു user-agent string അല്ലെങ്കിൽ സ്വയം തിരഞ്ഞെടുത്ത client name ഉപയോഗിച്ച് തന്നെ തിരിച്ചറിയുന്നു. ഇവ രണ്ടും പകർത്താൻ വളരെ എളുപ്പമാണ്. ഒരു message signature അതിനേക്കാൾ വ്യത്യസ്തമാണ്: അത് ഒരു request-നെ ഒരു key-യുമായി ബന്ധിപ്പിക്കുന്നു, private key-യുടെ ഉടമയ്ക്കേ സാധുവായ signature സൃഷ്ടിക്കാൻ കഴിയൂ. crawlers, assistants, autonomous agents എന്നിവയിൽ നിന്ന് traffic സ്വീകരിക്കുന്ന ഒരു application-ക്ക്, ഇത് "ഈ client പറയുന്നു അത് X ആണെന്ന്" എന്നതിനെ "ഈ request X പ്രസിദ്ധീകരിച്ച key ഉപയോഗിച്ച് ഒപ്പിട്ടതാണ്" എന്നതാക്കി മാറ്റുന്നു.

ആ ഭേദമാണ് സഹകരിക്കുന്ന automated clients-നെ anonymous traffic-ിന് പകരം അറിയപ്പെടുന്ന participants ആയി കൈകാര്യം ചെയ്യുന്നതിനുള്ള അടിസ്ഥാനം. ഇത് ഒരു API-ക്ക് signed crawler-നെ ഒരു structured endpoint-ലേക്ക് route ചെയ്യാനും, അറിയപ്പെടുന്ന operator-ന് വേറിട്ട rate limit പ്രയോഗിക്കാനും, അല്ലെങ്കിൽ ഒരു MCP server-ന് ഒരു tool വിളിക്കുന്നത് ആരാണെന്ന് കൂടുതൽ context നൽകാനും സഹായിക്കുന്നു.

Verification പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു

1. Signature-Inputയും Signatureയും parse ചെയ്ത് പ്രതീക്ഷിക്കുന്ന ഘടകങ്ങൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക. ഉപയോഗപ്രദമായ ഒന്നും ഉൾപ്പെടുത്താത്ത ഒരു signature വളരെ കുറച്ചേ തെളിയിക്കൂ.
2. createdയും expiresയും ഉള്ള parameters പരിശോധിച്ച്, നിങ്ങളുടെ സഹിഷ്ണുതയ്ക്കുള്ളിൽ പഴകിയതോ replay ചെയ്തതോ ആയ requests നിരസിക്കുക (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 കൃത്യമായി പുനർനിർമിച്ച്, പ്രഖ്യാപിച്ച algorithm ഉപയോഗിച്ച് അത് verify ചെയ്യുക.
5. എന്താണ് verified ആയത്, ഏത് context-ൽ ആയിരുന്നു അത് എന്ന് രേഖപ്പെടുത്തുക, പിന്നീട് തീരുമാനങ്ങൾ അതിനെ ആശ്രയിക്കാൻ കഴിയുന്ന വിധത്തിൽ.

production-ൽ, കൈയ്യോടെ എഴുതിയ parsing-നേക്കാൾ പരിപാലിക്കപ്പെടുന്ന ഒരു RFC 9421 implementation ഉപയോഗിക്കുക: canonicalization വിശദാംശങ്ങളിൽ പിഴവ് വരാൻ എളുപ്പമാണ്. signed AI agent requests എങ്ങനെ verify ചെയ്യാം എന്ന ഗൈഡ് code സഹിതം ഓരോ ഘട്ടവും വിശദീകരിക്കുന്നു.

സാധുവായ ഒരു signature എന്ത് തെളിയിക്കുന്നു, എന്ത് തെളിയിക്കുന്നില്ല

ഒരു സാധുവായ signature തെളിയിക്കുന്നത് request ഒരു key ഉപയോഗിച്ച് ഒപ്പിട്ടതാണെന്നും, ആ key ഒരു domain-ന് കീഴിൽ പ്രസിദ്ധീകരിച്ചിട്ടുണ്ടെങ്കിൽ, ആ request ആ domain-ന്റെ operator-നുമായി ബന്ധപ്പെട്ടതാണെന്നും ആണ്. ഇത് തെളിയിക്കാത്തത്:

• operator സത്യസന്ധനാണോ അല്ലെങ്കിൽ പ്രവർത്തനം സുരക്ഷിതമാണോ എന്ന്,
• ഒരു person request നിർദ്ദേശിച്ചോ അംഗീകരിച്ചോ എന്ന് (delegated authority കാണുക),
• client അത് ചോദിക്കുന്നത് ചെയ്യാൻ അനുവാദമുള്ളതാണോ എന്ന് (agent authorization കാണുക).

identity evidence-ഉം permission-ഉം വേറിട്ട ചോദ്യങ്ങളാണ്. നിങ്ങളുടെ application's സ്വന്തം authentication and authorization ആണ് ഒരു client എന്ത് ചെയ്യാമെന്ന് ഇപ്പോഴും തീരുമാനിക്കുന്നത്. signed AI agent requests എന്ത് തെളിയിക്കുന്നു, എന്തല്ല എന്ന ഞങ്ങളുടെ blog post ഇതിനെ കൂടുതൽ വിശദമായി ഉൾക്കൊള്ളുന്നു.

സാധാരണ തെറ്റിദ്ധാരണകൾ

• "Signed means trusted." Signed എന്നാൽ attributable എന്നാണ്. Trust എന്നത് attributed partyയെക്കുറിച്ച് നിങ്ങൾ എടുക്കുന്ന ഒരു policy തീരുമാനം ആണ്.
• "Signatures API keys-നെ പകരം വയ്ക്കുന്നു." അവ വേറിട്ട ചോദ്യങ്ങൾക്കാണ് മറുപടി നൽകുന്നത്. ഒരു API key ഏത് account ആണ് വിളിക്കുന്നത് എന്ന് പറയുന്നു; ഒരു signature ഏത് client ആണ് request സൃഷ്ടിച്ചത് എന്ന് പറയുന്നു. പല deployment-കൾക്കും രണ്ടും ഒരുമിച്ച് ഗുണകരമാണ്.
• "Unsigned traffic malicious ആണ്." ഇന്ന് ഉള്ള automated traffic-ന്റെ ഭൂരിഭാഗവും unsigned ആണ്. signatures ഇല്ലാത്തത് സ്ഥാപിക്കാനാകുന്നതിനെ കുറയ്ക്കുന്നു, അതിലധികം ഒന്നുമല്ല. അതുകൊണ്ടാണ് Unknown ഒരു first-class ഫലമായിരിക്കുന്നത്.

Proof of Actor signatures-നെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു

Proof of Actor-ൽ, പ്രസിദ്ധീകരിച്ച key-യ്‌ക്കെതിരേ validate ചെയ്യുന്ന ഒരു signature verified എന്ന basis-ോടെ രേഖപ്പെടുത്തുന്നു, പരിശോധന സ്ഥാപിച്ചതിന്റെ കൃത്യമായ പരിധിയിലേക്ക് മാത്രം: keyയും അതിന് അനുബന്ധിച്ച identifier-ഉം. ലഭിക്കുന്ന class (സാധാരണ Agent) ഒരിക്കലും authorization സൂചിപ്പിക്കുന്നില്ല. ഫലങ്ങൾ analysis-നായി Understand-ലേക്കും, നിങ്ങളുടെ സ്വന്തം policies ഒരു signed client-ന് structured path, വ്യത്യസ്ത limit, അല്ലെങ്കിൽ ഒരു മാറ്റവും ഇല്ലാത്ത നില എന്നിവ നൽകണമോ എന്ന് തീരുമാനിക്കുന്ന Route-ലേക്കും ഒഴുകുന്നു. Web Bot Auth പോലുള്ള signed-agent standards വികസിച്ചുകൊണ്ടിരിക്കുകയാണ്, Proof of Actor അവ成熟മാകുന്ന പോലെ signed requests verify ചെയ്യുന്നതിനായാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

എന്താണ് evidence സ്ഥാപിക്കാൻ കഴിയുന്നത് എന്നതിനെ കുറിച്ച് കൂടുതൽ വായിക്കുക, അല്ലെങ്കിൽ early access-ന് അപേക്ഷിക്കുക.

Sources

• RFC 9421: HTTP Message Signatures: signature components, parameters and verification നിർവചിക്കുന്ന IETF standard
• RFC 9651: HTTP-നുള്ള Structured Field Values: Signature-Input and Signature-ന്റെ syntax
• draft-ietf-webbotauth-httpsig-protocol: automated clients-ക്ക് RFC 9421 പ്രയോഗിക്കുന്ന IETF Web Bot Auth draft (November 2026-നാടകം work in progress)