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 மற்றும் alg போன்ற அளவுருக்களும் பட்டியலிடப்படுகின்றன, மற்றும் Signature (Section 4.2), இதில் கையொப்பத்தின் மதிப்பு itself எடுத்துச் செல்லப்படுகிறது. இரண்டும் RFC 9651-இன் Structured Field Values syntax-ஐ பயன்படுத்துகின்றன.

பெறுநர் தான் உண்மையில் பெற்ற கோரிக்கையிலிருந்து அதே signature base-ஐ (Section 2.5) மீண்டும் உருவாக்குகிறது, keyid மூலம் குறிப்பிடப்பட்ட public key-ஐ தேடுகிறது, மற்றும் கையொப்பத்தைச் சரிபார்க்கிறது. கையொப்பத்தால் கவரேஜில் உள்ள ஏதாவது ஒன்று பரிமாற்றத்தின் போது மாறினால், verification தோல்வியடைகிறது.

Apps, APIs மற்றும் MCP servers-க்கு இது ஏன் முக்கியம்

பெரும்பாலான தானியங்கி போக்குவரத்து தன்னை ஒரு user-agent string அல்லது தானாகத் தேர்ந்த client பெயரால் அடையாளப்படுத்துகிறது. இரண்டும் எளிதில் நகலெடுக்கக்கூடியவை. Message signature வேறுபட்டது: அது ஒரு கோரிக்கையை ஒரு விசையுடன் இணைக்கிறது, மேலும் private key-யின் வைத்திருப்பவரால் மட்டுமே செல்லுபடியாகும் signature-ஐ உருவாக்க முடியும். crawlers, assistants மற்றும் autonomous agents-இலிருந்து traffic பெறும் ஒரு application-க்கு, இது "இந்த client தன்னை X என்று கூறுகிறது" என்பதைக் "இந்த request X வெளியிடும் விசையால் கையொப்பமிடப்பட்டது" என்பதாக மாற்றுகிறது.

அந்த வேறுபாடே ஒத்துழைக்கும் தானியங்கி clients-ஐ அநாமதேய traffic ஆக அல்லாமல் தெரிந்த பங்கேற்பாளர்களாக கையாளும் அடிப்படை. இது ஒரு API-க்கு signed crawler-ஐ ஒரு structured endpoint-க்கு வழிமாற்ற, தெரிந்த operator-க்கு வேறுபட்ட rate limit-ஐப் பயன்படுத்த, அல்லது ஒரு MCP server-க்கு யார் ஒரு tool-ஐ அழைக்கிறார்கள் என்பதற்கான கூடுதல் context-ஐ வழங்க உதவுகிறது.

Verification நடைமுறையில் எப்படி இயங்குகிறது

1. Signature-Input மற்றும் Signature-ஐ parse செய்து, எதிர்பார்க்கப்படும் கூறுகள் கவரேஜில் உள்ளனவா என்பதை உறுதிசெய்க. பயனுள்ள எதையும் கவரேஜ் செய்யாத signature மிகக் குறைவையே நிரூபிக்கிறது.
2. created மற்றும் expires அளவுருக்களைச் சரிபார்த்து, உங்கள் tolerance-க்குள் பழைய அல்லது replay செய்யப்பட்ட கோரிக்கைகளை நிராகரிக்கவும் (signature replay குறித்து Section 7.2.2-ஐ பார்க்கவும்).
3. keyid-ஐ நீங்கள் நம்பும் ஒரு மூலத்திலிருந்து public key-க்கு resolve செய்யவும், உதாரணமாக operator அறியப்பட்ட இடத்தில் வெளியிடும் key directory. தானியங்கி clients-க்கு IETF Web Bot Auth protocol draft அத்தகைய directory-ஐ வரையறுக்கிறது.
4. குறிப்பிடப்பட்டபடியே signature base-ஐ மீண்டும் உருவாக்கி, declared algorithm-ஐ பயன்படுத்தி அதை verify செய்யவும்.
5. என்ன verify செய்யப்பட்டது மற்றும் எந்த context-இல் என்பதை பதிவு செய்யவும், அதனால் பின்னர் எடுக்கப்படும் முடிவுகள் அதை மேற்கோள் காட்ட முடியும்.

உற்பத்தியில், கையால் எழுதப்பட்ட parsing-ஐ விட பராமரிக்கப்படும் RFC 9421 implementation-ஐப் பயன்படுத்தவும்: canonicalization விவரங்களில் தவறுவது எளிது. How to verify signed AI agent requests என்ற வழிகாட்டி ஒவ்வொரு படியையும் code உடன் விளக்குகிறது.

செல்லுபடியாகும் signature எதை நிரூபிக்கிறது, எதை நிரூபிக்கவில்லை

செல்லுபடியாகும் signature, request ஒரு விசையால் கையொப்பமிடப்பட்டது என்பதை நிரூபிக்கிறது, மேலும் அந்த விசை ஒரு domain கீழ் வெளியிடப்பட்டிருந்தால், request அந்த domain-இன் operator-இன் தொடர்புடையது என்பதை நிரூபிக்கிறது. அது இதை நிரூபிக்காது:

• operator நேர்மையானவர் அல்லது செயல் பாதுகாப்பானது என்பதை,
• ஒரு நபர் request-ஐ அறிவுறுத்தினார் அல்லது அங்கீகரித்தார் என்பதை (delegated authority-ஐ பார்க்கவும்),
• client தன்னிடம் கேட்கும் செயலைச் செய்ய அனுமதிக்கப்பட்டது என்பதை (agent authorization-ஐ பார்க்கவும்).

Identity evidence மற்றும் permission என்பது தனித்த கேள்விகள். உங்கள் application-இன் சொந்த authentication மற்றும் authorization தான் ஒரு client என்ன செய்ய முடியும் என்பதை இன்னும் தீர்மானிக்கின்றன. signed AI agent requests என்ன நிரூபிக்கின்றன, என்ன நிரூபிக்கவில்லை என்ற எங்கள் blog post இதை மேலும் விரிவாகக் கூறுகிறது.

பொதுவான தவறான புரிதல்கள்

• "Signed என்றால் trusted." Signed என்றால் attributed என்பதாகும். Trust என்பது நீங்கள் அந்த attributed party குறித்து எடுக்கும் policy முடிவு.
• "Signatures API keys-ஐ மாற்றிவிடும்." அவை வேறு கேள்விக்கு பதிலளிக்கின்றன. ஒரு API key எந்த account அழைக்கிறது என்பதைச் சொல்கிறது; ஒரு signature எந்த client request-ஐ உருவாக்கியது என்பதைச் சொல்கிறது. பல deployment-கள் இரண்டாலும் பயன் பெறுகின்றன.
• "Unsigned traffic என்பது malicious." இன்று உள்ள பெரும்பாலான தானியங்கி traffic unsigned ஆகும். Signature இல்லாததால் நிரூபிக்க முடிவது குறைகிறது, அதைவிட இல்லை. அதனால்தான் Unknown ஒரு முதன்மை முடிவாக இருக்கிறது.

Proof of Actor signatures-ஐ எப்படி கையாளுகிறது

Proof of Actor-இல், வெளியிடப்பட்ட key-க்கு எதிராக validate ஆகும் ஒரு signature, சரிபார்ப்பால் நிறுவப்பட்டதன் துல்லியமான எல்லைக்குள், basis verified-ஆக பதிவு செய்யப்படுகிறது: key மற்றும் அது சேர்ந்த identifier. இதனால் கிடைக்கும் class (பொதுவாக Agent) authorization-ஐ ஒருபோதும் குறிக்காது. முடிவுகள் analysis-க்காக Understand-க்கு, மேலும் உங்கள் சொந்த policies signed client-க்கு structured path, வேறுபட்ட limit, அல்லது எந்த மாற்றமும் இல்லாத நிலை கிடைக்குமா என்பதைத் தீர்மானிக்கும் Route-க்கு செல்லும். Web Bot Auth போன்ற signed-agent standards வளர்ந்து வருகின்றன, மேலும் அவை முதிர்ச்சியடையும் போது signed requests-ஐ verify செய்யும் வகையில் Proof of Actor வடிவமைக்கப்பட்டுள்ளது.

evidence என்ன நிறுவ முடியும் பற்றி மேலும் படிக்கவும், அல்லது early access-க்கு விண்ணப்பிக்கவும்.

Sources

• RFC 9421: HTTP Message Signatures: signature கூறுகள், அளவுருக்கள் மற்றும் verification-ஐ வரையறுக்கும் IETF தரநிலை
• RFC 9651: Structured Field Values for HTTP: Signature-Input மற்றும் Signature-இன் syntax
• draft-ietf-webbotauth-httpsig-protocol: தானியங்கி clients-க்கு RFC 9421-ஐப் பயன்படுத்தும் IETF Web Bot Auth draft (November 2026 நிலவரப்படி work in progress)