HTTP Message Signatures (RFC 9421)

HTTP Message Signatures ఏమిటి

HTTP Message Signatures RFC 9421 లో నిర్వచించబడ్డాయి, ఇది HTTP request లేదా response లోని భాగాలపై digital signatures సృష్టించడానికి మరియు verify చేయడానికి ఉపయోగించే IETF standard. client ఏ components ను cover చేయాలో ఎంచుకుంటుంది (ఉదాహరణకు method, target URI, authority, మరియు selected headers), వాటితో ఒక canonical signature base నిర్మిస్తుంది, మరియు దాన్ని private key తో sign చేస్తుంది. ఫలితం రెండు headers లో ప్రయాణిస్తుంది: Signature-Input (Section 4.1), ఇది covered components మరియు created, expires, keyid మరియు alg వంటి parameters ను జాబితా చేస్తుంది, మరియు Signature (Section 4.2), ఇది signature value ను itself కలిగి ఉంటుంది. రెండింటూ RFC 9651 యొక్క Structured Field Values syntax ను ఉపయోగిస్తాయి.

receiver అది నిజంగా అందుకున్న request నుంచే అదే signature base (Section 2.5) ను మళ్లీ నిర్మిస్తుంది, keyid ద్వారా సూచించబడిన public key ను look up చేస్తుంది, మరియు signature ను check చేస్తుంది. signature ద్వారా cover చేయబడిన ఏదైనా transit లో మారితే, verification fail అవుతుంది.

అవి apps, APIs మరియు MCP servers కు ఎందుకు ముఖ్యమో

చాలా automated traffic user-agent string లేదా స్వయంగా ఎంచుకున్న client name ద్వారా తనను తాను identify చేస్తుంది. రెండింటినీ copy చేయడం చాలా సులభం. message signature వేరుగా ఉంటుంది: అది request ను ఒక key తో tie చేస్తుంది, మరియు private key holder మాత్రమే valid signature ను produce చేయగలడు. crawlers, assistants మరియు autonomous agents నుండి traffic అందుకునే application కోసం, ఇది "ఈ client తనను X అని చెబుతోంది" అనే మాటను "ఈ request X publish చేసిన key ద్వారా sign చేయబడింది"గా మారుస్తుంది.

ఆ తేడా cooperating automated clients ను anonymous traffic కాకుండా known participants గా treat చేయడానికి పునాది. ఇది ఒక API కు signed crawler ను structured endpoint కు route చేయడానికి, తెలిసిన operator కు వేరే rate limit apply చేయడానికి, లేదా ఒక MCP server కు ఒక tool ను ఎవరు call చేస్తున్నారు అనే విషయంపై మరింత context ఇవ్వడానికి సహాయపడుతుంది.

verification ప్రాక్టికల్‌గా ఎలా పని చేస్తుంది

1. Signature-Input మరియు Signature ను parse చేసి, expected components cover చేయబడ్డాయో confirm చేయండి. ఏ ఉపయోగకరమైనదీ cover చేయని signature తక్కువే నిరూపిస్తుంది.
2. stale లేదా replay చేసిన requests ను మీ tolerance లో reject చేయడానికి created మరియు expires parameters ను check చేయండి (signature replay పై Section 7.2.2 చూడండి).
3. keyid ను మీరు trust చేసే source నుంచే వచ్చిన public key కు resolve చేయండి, ఉదాహరణకు operator known location లో publish చేసే key directory. IETF Web Bot Auth protocol draft automated clients కోసం అలాంటి directory ను define చేస్తుంది.
4. specified చేసిన విధంగా signature base ను ఖచ్చితంగా మళ్లీ నిర్మించి, declared algorithm తో verify చేయండి.
5. ఏమి verified అయిందో, ఏ context లో అయిందో record చేయండి, తద్వారా తరువాతి decisions దానిని reference చేయగలవు.

production లో, చేతితో రాసిన parsing కంటే maintained RFC 9421 implementation ను వాడండి: canonicalization details లో తప్పు చేయడం సులభం. how to verify signed AI agent requests పై guide ప్రతి step ను code తో వివరిస్తుంది.

valid signature ఏమి నిరూపిస్తుంది, ఏమి నిరూపించదు

valid signature request ఒక key ద్వారా sign చేయబడిందని, మరియు key ఒక domain కింద publish చేయబడితే, request ఆ domain యొక్క operator తో associated అని నిరూపిస్తుంది. ఇది నిరూపించేది కాదు:

• operator honest అని లేదా action safe అని,
• ఒక person request ను instruct చేశాడని లేదా approve చేశాడని (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 అంటే attributable. Trust అనేది మీరు attributed party గురించి తీసుకునే policy decision.
• "Signatures API keys ను replace చేస్తాయి." అవి వేరే ప్రశ్నలకు సమాధానం ఇస్తాయి. API key ఏ account calling చేస్తుందో చెబుతుంది; signature ఏ client request ను produce చేసిందో చెబుతుంది. చాలా deployments రెండింటి వల్ల లాభపడతాయి.
• "Unsigned traffic malicious." ఈ రోజుల్లో ఎక్కువ automated traffic unsigned గా ఉంటుంది. signatures లేకపోవడం వల్ల establish చేయగలిగేది తగ్గుతుంది, అంతే. అందుకే Unknown ఒక first-class result.

Proof of Actor signatures ను ఎలా treat చేస్తుంది

Proof of Actor లో, published key పై validate అయ్యే signature ను basis verified తో record చేస్తారు, check ఏమి establish చేసిందో దాని కచ్చితమైన పరిమితిలో: key మరియు అది చెందిన identifier. దాని వల్ల వచ్చిన class (సాధారణంగా Agent) ఎప్పటికీ authorization ను imply చేయదు. results Understand లో analysis కోసం, మరియు Route లోకి ప్రవేశిస్తాయి, అక్కడ మీ own policies ఒక signed client కు structured path, వేరే limit, లేదా ఎలాంటి change లేకుండా ఉంచాలా అనేది నిర్ణయిస్తాయి. Web Bot Auth వంటి signed-agent standards evolve అవుతూనే ఉన్నాయి, మరియు Proof of Actor అవి mature అవుతున్న కొద్దీ signed requests ను verify చేయడానికి రూపొందించబడింది.

evidence ఏమిని establish చేయగలదో గురించి మరింత చదవండి, లేదా early access కోసం apply చేయండి.

మూలాలు

• 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 ను apply చేసే IETF Web Bot Auth draft (November 2026 నాటికి work in progress)