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 અને પસંદ કરેલા 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 પોતે હોય છે. બંને RFC 9651 ના Structured Field Values syntax નો ઉપયોગ કરે છે.

Receiver તેને actually received request પરથી એ જ signature base (Section 2.5) ફરી બનાવે છે, keyid દ્વારા સંદર્ભિત public key શોધે છે, અને signature ચકાસે છે. જો signature દ્વારા cover કરેલું કોઈપણ ભાગ transit દરમિયાન બદલાઈ ગયું હોય, તો verification નિષ્ફળ જાય છે.

તે apps, APIs અને MCP servers માટે કેમ મહત્વપૂર્ણ છે

મોટાભાગનો automated traffic પોતાને user-agent string અથવા self-chosen client name થી ઓળખાવે છે. બંને સરળતાથી copy કરી શકાય છે. Message signature અલગ છે: તે request ને એક key સાથે જોડે છે, અને માત્ર private key નો holder માન્ય signature બનાવી શકે છે. Crawlers, assistants અને autonomous agents તરફથી traffic મેળવનાર application માટે, તેનો અર્થ થાય છે કે "આ client કહે છે કે તે X છે" ને બદલે "આ request X publish કરે છે એવી key દ્વારા sign કરવામાં આવી હતી".

આ ભેદ cooperating automated clients ને anonymous traffic બદલે જાણીતા participants તરીકે ગણવાની આધારશિલા છે. તે API ને signed crawler ને structured endpoint તરફ route કરવા, જાણીતા operator માટે અલગ rate limit લાગુ કરવા, અથવા MCP server ને tool call કરનાર વિશે વધુ context આપવા દે છે.

verification વાસ્તવમાં કેવી રીતે કામ કરે છે

1. Signature-Input અને Signature parse કરો અને expected components covered છે તેની પુષ્ટિ કરો. જે signature કોઈ ઉપયોગી વસ્તુ cover કરતી નથી તે બહુ ઓછું સાબિત કરે છે.
2. created અને expires parameters તપાસો, જેથી તમારી tolerance અંદર stale અથવા replay થયેલી requests reject કરી શકાય (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 ની વ્યાખ્યા કરે છે.
4. જણાવ્યા મુજબ signature base exactly ફરી બનાવો અને declared algorithm વડે તેને verify કરો.
5. શું verify થયું અને કયા context માં થયું તે record કરો, જેથી પછીના નિર્ણયો તેનો reference લઈ શકે.

Production માં, હાથથી બનાવેલી parsing કરતાં maintained RFC 9421 implementation નો ઉપયોગ કરો: canonicalization ની વિગતોમાં ભૂલ થવી સરળ છે. how to verify signed AI agent requests પરનો guide code સાથે દરેક step બતાવે છે.

માન્ય signature શું સાબિત કરે છે અને શું નથી કરતું

માન્ય signature સાબિત કરે છે કે request કોઈ key વડે sign કરવામાં આવી હતી, અને જો key કોઈ domain હેઠળ publish કરવામાં આવી હોય, તો request તે domain ના operator સાથે સંકળાયેલી છે. તે આ સાબિત કરતું નથી:

• operator ઈમાનદાર છે અથવા 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 એટલે attributed. Trust એ તમે attributed party વિશે લેવાનો policy decision છે.
• "Signatures API keys ને બદલે છે." તે અલગ પ્રશ્નોના જવાબ આપે છે. API key જણાવે છે કે કયો account call કરી રહ્યો છે; signature જણાવે છે કે request કયા client એ બનાવી છે. ઘણાં deployments માટે બંને ઉપયોગી છે.
• "Unsigned traffic malicious છે." આજે મોટાભાગનો automated traffic unsigned છે. Missing signatures થી શું establish કરી શકાય તે ઓછું થાય છે, એટલું જ. તેથી Unknown ને first-class result ગણવામાં આવે છે.

Proof of Actor signatures ને કેવી રીતે扱ે છે

Proof of Actor માં, published key સામે validate થતી signature ને basis verified સાથે record કરવામાં આવે છે, અને verification એ જે સ્થાપિત કર્યું છે એટલા સુધી scope થાય છે: key અને તેનું identifier. પરિણામે મળતો class (સામાન્ય રીતે Agent) ક્યારેય authorization સૂચવતો નથી. Results analysis માટે Understand માં અને Route માં flow થાય છે, જ્યાં તમારી પોતાની policies નક્કી કરે છે કે signed client ને structured path મળે, અલગ limit મળે, કે કોઈ change ન થાય. Web Bot Auth જેવા signed-agent standards વિકસિત થઈ રહ્યા છે, અને Proof of Actor એવા signed requests ને verify કરવા માટે રચાયેલ છે જેમ જેમ તે mature થાય છે.

વધુ જાણો 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)