EMILIA Protocol

EMILIA Protocol

---

अपने एजेंट से भुगतान तैयार करवाएँ। यह नियंत्रित करें कि वह क्या जारी कर सकता है।

एक एजेंट $82,000 का आपूर्तिकर्ता भुगतान तैयार करता है। कोई व्यक्ति उसे मंज़ूरी देता है। फिर राशि या बैंक गंतव्य बदल जाता है। पहले की मंज़ूरी से बदले हुए भुगतान को जारी नहीं किया जाना चाहिए।

EMILIA Gate किसी संरक्षित टूल के चलने से पहले प्राधिकरण की जाँच करता है। खुला प्रोटोकॉल यह सुनिश्चित करता है कि परिणामी साक्ष्य को सत्यापनकर्ता की अपनी विश्वसनीय कुंजियों और नियमों के तहत स्वतंत्र रूप से जाँचा जा सके। अपने मौजूदा पहचान प्रदाता, एजेंट फ़्रेमवर्क और व्यावसायिक प्रणालियों को बनाए रखें।

भुगतान का उदाहरण चलाएँ

Node.js 20.19 या नया संस्करण और npm इंस्टॉल होने पर:

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

यह उदाहरण मंज़ूरी के बिना कॉल को अस्वीकार करता है, मंज़ूरी को राशि, मुद्रा, विक्रेता और गंतव्य से बाँधता है, मेल खाने वाली कॉल को एक बार स्वीकार करता है, और बदले हुए भुगतान विवरण, दोबारा चलाने तथा जाली साक्ष्य को अस्वीकार करता है। उदाहरण और इसकी सीमाएँ देखें।

यह एक स्थानीय प्रदर्शन है: इसमें बनाई गई हस्ताक्षर कुंजियाँ, मेमोरी में उपभोग और एक नकली भुगतान टूल शामिल हैं। यह वास्तविक मानवीय अनुमोदन प्रक्रिया नहीं करता और न ही धन हस्तांतरित करता है। उत्पादन के लिए नामांकित क्रेडेंशियल, टिकाऊ साझा स्थिति और संरक्षित प्रदाता क्रेडेंशियल तक जाने वाले हर रास्ते पर Gate आवश्यक है। वैध मंज़ूरी यह साबित नहीं करती कि बैंक विवरण वैध हैं।

ब्राउज़र पसंद है? नमूना भुगतान पर पासकी आज़माएँ। यह अलग डेमो आपके प्लेटफ़ॉर्म ऑथेंटिकेटर के साथ रसीद की अखंडता दिखाता है; कोई भुगतान नहीं भेजा जाता।

अपने पहले से उपयोग किए जा रहे किसी एक टूल को सुरक्षित करें

उस सेवा से शुरुआत करें जिसके पास वास्तविक प्रदाता क्रेडेंशियल है, केवल एजेंट की प्रक्रिया के भीतर से नहीं। स्वामी तय करता है कि कौन-सा काम अनुमत है और कब नई मंज़ूरी आवश्यक है। एजेंट इन सीमाओं के भीतर काम कर सकता है, बिना हर कॉल के लिए किसी व्यक्ति से मंज़ूरी लिए।

• MCP या HTTP: Gate Starter एक संरक्षित कार्रवाई की प्रक्रिया बताता है।
• Hugging Face smolagents: मौजूदा टूल को रैप करें।
• GitHub: Merge Gate जाँच को प्रस्तावित मर्ज से बाँधता है। जाँच अनिवार्य होनी चाहिए और मर्ज के वैकल्पिक रास्ते बंद होने चाहिए।

प्रोटोकॉल प्रमाणित करता है। Gate रोकता है उन रास्तों पर जिनका परिनियोजन पूरी तरह मध्यस्थता करता है। Gate किसी बाईपास रास्ते को नियंत्रित नहीं कर सकता। यदि प्रदाता का परिणाम अज्ञात हो, तो उत्पादन जीवनचक्र उस अनिश्चितता को बिना सोचे-समझे दोबारा प्रयास करने के बजाय समाधान के लिए सुरक्षित रखता है।

AI प्रणालियों और रिपॉज़िटरी समीक्षकों के लिए: AI_CONTEXT.md से शुरुआत करें। वर्तमान मशीन-पठनीय साक्ष्य, उद्गम, मान्यताएँ और अपवर्जन EMILIA-REPO-CONTEXT-v1 पर प्रकाशित हैं। संग्रहीत या चरणबद्ध दस्तावेज़ वर्तमान कार्यान्वयन या IETF स्थिति स्थापित नहीं करते। सार्वजनिक समुचित-जाँच साक्ष्य और दावों की सीमाएँ: DUE_DILIGENCE.md।

वास्तुकला के दावों के बजाय इंजीनियरिंग साक्ष्य

EMILIA एक ऐसा सुरक्षा मामला उपलब्ध कराता है जिसे समीक्षक स्वयं चला सकते हैं। वर्तमान रिपॉज़िटरी 264 हैश किए गए साक्ष्य फ़ाइलों पर 35 सुरक्षा दावों का समाधान करती है, दो संयोजित Dolev-Yao मॉडलों में 20 Tamarin लेम्मा सत्यापित करती है — 17 सभी-ट्रेस दायित्व और 3 अस्तित्व-ट्रेस पहुँच-योग्यता साक्ष्य — और 8 जानबूझकर कमजोर किए गए रूप सुरक्षित रखती है, जो महत्वपूर्ण जाँचें हटाने पर ठोस आक्रमण ट्रेस उत्पन्न करते हैं। सक्रिय, उसी टीम का अनुरूपता कॉर्पस 21 सुइट और 340 वर्तमान वेक्टर रखता है। अलग से, बाहरी रूप से लिखित Rust सत्यापनकर्ता को स्थिर 16-सुइट/164-वेक्टर बंडल और 359-केस शत्रुतापूर्ण परीक्षण अभियान पर पिन किया गया है। व्यापक सुइट में 650+ फ़ाइलों में 10,700+ स्वचालित परीक्षण हैं।

उत्पादन JavaScript और JSDoc सतहों की TypeScript से कंपाइलर-जाँच की जाती है checkJs; सुरक्षित ऐप का अपना संगतता कंपाइलर प्रोजेक्ट है, जबकि घोषणाओं और सार्वजनिक TypeScript SDK की सख्त मोड में जाँच की जाती है। यह कॉन्फ़िगर किए गए उत्पादन प्रकार-जाँच कवरेज की पूर्णता है; इसका अर्थ यह दावा नहीं है कि पूरी रिपॉज़िटरी को JavaScript से TypeScript में बदल दिया गया है या हर JavaScript प्रोजेक्ट में TypeScript का strict विकल्प सक्षम है।

हर सुरक्षा दावा प्रवर्तन पथ, सकारात्मक और नकारात्मक वेक्टर, भाषा कवरेज, औपचारिक दायरा या स्पष्ट अंतर, मान्यताएँ, अपवर्जन और साक्ष्य हैश बताता है। शुरुआत मानव-पठनीय साक्ष्य मानचित्र से करें, फिर समाधान किए गए सुरक्षा मामले की जाँच करें या npm run check:security-case चलाएँ।

AEB-1: साक्ष्य-से-प्रभाव सीमा का परीक्षण करें

खुला AEB-1 Consequence Admission Conformance पैक, किसी परिणामकारी कार्रवाई से ठीक पहले के अंतिम नियंत्रण बिंदु पर संयोजित CAID/AEC पथ का परीक्षण करता है: मूल सत्यापन, निर्भर-पक्ष स्वीकृति, सटीक-कार्रवाई बाइंडिंग, आवश्यक CAID मिलान, आवश्यक AEC साक्ष्य की पूर्ति, स्थानीय प्राधिकरण, परमाण्विक आरक्षण, INVOKING अभिरक्षा, प्रदाता-परिणाम और देखे गए प्रभाव की अलग-अलग सत्यता, बिना अंधाधुंध पुनः-प्रयास का व्यवहार, और प्रमाणित समाधान।

संयोजित CAID/AEC पथ, प्रत्यक्ष मूल पथ, AEB अभिरक्षा और प्रदाता-परिणाम साक्ष्य के बीच ज़िम्मेदारी के सटीक विभाजन के लिए परिणाम-स्वीकृति सीमा पढ़ें।

npx @emilia-protocol/verify aeb-conformance --reference

यह फ़ॉर्मैट-निरपेक्ष है और इसे स्वयं चलाया जा सकता है। सफल रिपोर्ट स्व-प्रमाणित अनुरूपता साक्ष्य है; यह ऑडिट, प्रमाणन, उत्पादन-परिनियोजन का दावा या कार्रवाई निष्पादित करने की अनुमति नहीं है।

AEB-07 के तहत, जिसे 2026-09-25 को एक व्यक्तिगत Internet-Draft के रूप में प्रकाशित किया गया था और किसी कार्यसमूह ने नहीं अपनाया, CAID का उपयोग केवल तभी किया जाता है जब स्वतंत्र रूप से एन्कोड की गई कार्रवाइयों को जोड़ना आवश्यक हो, और AEC का उपयोग केवल तभी किया जाता है जब स्थानीय नीति को कई साक्ष्य चरणों की आवश्यकता हो। एक अलग 26-केस सिंथेटिक कॉर्पस, AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token और स्थानीय हस्ताक्षरित अधिदेश एडेप्टर परिणामों पर उस प्रत्यक्ष-मूल जीवनचक्र का मॉडल बनाता है:

npm run conformance:composition:consequence-admission

कॉर्पस रनर एक स्वतंत्र जीवनचक्र मॉडल है, जिसका अपना मेमोरी-आधारित स्टोर और स्वीकृति तर्क है। यह भेजे गए @emilia-protocol/verify या @emilia-protocol/gate कोड को निष्पादित नहीं करता, इसलिए यह उन पैकेजों का साक्ष्य नहीं है; उनके अपने परीक्षण सुइट हैं। यह इस बात का साक्ष्य भी नहीं है कि उल्लिखित मूल प्रोटोकॉल AEB-07 के अनुरूप हैं।

रिपॉज़िटरी के Gate पथ का केंद्रित निष्पादन योग्य प्रमाण चलाने के लिए:

npm run proof:gate:reference

यह कमांड बनाई गई कुंजियों, मेमोरी-आधारित स्थिति और नकली प्रदाता व्यवहार के साथ स्थानीय उदाहरणों और केंद्रित सेवा सीमाओं का परीक्षण करता है। यह उपयोगी स्थानीय प्रमाण है, वास्तविक व्यक्ति, बाहरी बैंक, उत्पादन परिनियोजन या एक संपूर्ण उत्पादन एकीकरण का साक्ष्य नहीं।

पहचान नौकरी का विवरण नहीं है

पहचान बताती है कि कौन या क्या कॉल कर रहा है। नीति बताती है कि आम तौर पर क्या अनुमत है। इनमें से कोई भी यह परिभाषित नहीं करता कि कोई स्वायत्त कार्यकर्ता अभी कौन-सा सीमित काम कर सकता है: उसका मिशन, महत्वपूर्ण कार्रवाई की सीमाएँ, बजट, आवश्यक साक्ष्य, समाप्ति, प्रत्यायोजन नियम और अपवाद प्रक्रिया।

EMILIA इन प्रश्नों को अलग रखता है:

परत	प्रश्न
पहचान	कौन या क्या मौजूद है?
नीति	आम तौर पर क्या अनुमत है?
प्राधिकरण	इस अधिदेश के तहत यह एजेंट कौन-सा सटीक काम कर सकता है?

क्रेडेंशियल पहुँच प्रदान करते हैं। प्राधिकरण काम को परिभाषित करता है। हर कार्रवाई के लिए मानव आवश्यक नहीं; हर परिणामकारी कार्रवाई के लिए वैध प्राधिकरण आवश्यक है।

आधार स्तर पर, EP Core अब भी तीन परस्पर-संचालनीय ऑब्जेक्ट उपलब्ध कराता है: Trust Receipt आरोपणीय साक्ष्य रखता है, Trust Profile संरचित विश्वास स्थिति दर्शाता है, और Trust Decision निर्भर-पक्ष के नीति-मूल्यांकित परिणाम को दर्ज करता है। प्राधिकरण-नियंत्रण-प्लेन की परतें इन ऑब्जेक्ट को एक ही दावे में समेटे बिना सटीक कार्रवाई बाइंडिंग, सीमित अधिदेश, स्वीकृति, उपभोग और परिणाम साक्ष्य जोड़ती हैं।

---

अधिदेश एक बार तय करें। एजेंट को काम करने दें।

ग्राहक मिशन, सीमाएँ, साक्ष्य आवश्यकताएँ, समाप्ति और अपवाद नियम तय करता है। स्थानीय कोड उस प्राधिकरण को सीमित कर सकता है; वह इसे गढ़ या बढ़ा नहीं सकता। Gate हर निष्पादन योग्य अनुरोध को अधिदेश से बाँधता है, प्रदाता में प्रवेश से पहले संबंधित प्राधिकरण आरक्षित करता है, साझा टिकाऊ प्राधिकरण डोमेन के भीतर उस प्राधिकरण इंस्टेंस के लिए एक स्वीकृत प्रदाता प्रयास की अनुमति देता है, और केवल तभी मामला आगे बढ़ाता है जब प्राधिकरण अनुपस्थित, पुराना, समाप्त या बहुत सीमित हो।

बंडल किए गए MCP उदाहरण, सीमा पर मंज़ूरी आवश्यक करने वाली नीति प्रोफ़ाइल का परीक्षण करते हैं। वे प्रदर्शन के लिए हस्ताक्षर कुंजियाँ बनाते हैं और नकली टूल चलाते हैं। भुगतान उदाहरण सभी चार घोषित महत्वपूर्ण फ़ील्ड बाँधता है; अन्य उदाहरण अधिक सीमित संसाधन बाइंडिंग दिखाते हैं। वे वास्तविक मानवीय निर्णय दर्ज नहीं करते और न ही किसी प्रदाता से संपर्क करते हैं:

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

अधिक गहन संयोजन डेमो, Gate के वास्तविक सीमित-क्षमता पथ के माध्यम से CAID-बद्ध प्रत्यायोजित भुगतान निष्पादित करता है, फिर हस्ताक्षरित निष्पादन प्रमाणपत्र को ऑफ़लाइन सत्यापित करता है:

npm run demo:receipt-program

इसमें जानबूझकर कोई ब्लॉकचेन या नकली शून्य-ज्ञान दावा शामिल नहीं है। उत्पादन स्थिति और विश्वास आवश्यकताओं के लिए रसीद-प्रोग्राम वास्तुकला देखें।

एक घोषित परिणामकारी MCP कार्रवाई से शुरुआत करें। सटीक स्थानीय रनटाइम इंस्टॉल करें, फिर उसका Gate Starter बनाएँ और चार मामलों की सीमित जाँच चलाएँ:

npm install --save-exact @emilia-protocol/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

बनाई गई स्थानीय जाँच स्पष्ट रूप से अस्थायी डेमो स्थिति का उपयोग करती है और केवल बताए गए सिंथेटिक अनुपस्थित, सटीक-मिलान, बदलाव, पुनः-प्रयोग और बिना स्कैन किए गए टूल के मामलों को प्रमाणित करती है। समीक्षित कमांड गोपनीयता-सीमित हस्तांतरण तैयार करती है; यह Gate सक्रिय नहीं करती। उत्पादन के लिए टिकाऊ उद्गम लेज़र, साझा परमाण्विक उपभोग स्टोर, पिन की गई कुंजियाँ और वास्तविक प्रदाता क्रेडेंशियल तक जाने वाले हर रास्ते पर रैपर आवश्यक है। देखें examples/mcp/ और /mcp।

पुराने कार्यों को वापस लेने का दिखावा किए बिना नई कार्रवाइयाँ रोकें

Gate का आपातकालीन प्राधिकरण फ़्रीज़ नए आरक्षणों को रोकता है और कवर किए गए नियंत्रण डोमेन का epoch बदलने के बाद पुराने आरक्षणों को प्रवेश करने से रोकता है। यदि प्रदाता में प्रवेश पहले हो चुका था, तो प्रयास उपभोग किया हुआ रहता है और उसका समाधान आवश्यक है। प्राधिकरण बहाल करने से पुराना आरक्षण फिर सक्रिय नहीं होता।

इसके लिए पूर्ण मध्यस्थता और प्रामाणिक साझा स्थिति आवश्यक है। यह गणना नहीं रोकता, किसी प्रभाव को उलटता नहीं और अलग-थलग डोमेन तक तुरंत नहीं पहुँचता। नियंत्रण-डोमेन कार्यान्वयन और सीमाएँ देखें।

30 सेकंड में आज़माएँ

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

नमूना भुगतान पर प्लेटफ़ॉर्म पासकी आज़माएँ → एक उदाहरणात्मक $82,000 भुगतान पर हस्ताक्षर करें, उसकी राशि बदलें और देखें कि अखंडता जाँच विफल हो जाती है। आपका ऑथेंटिकेटर बायोमेट्रिक्स या डिवाइस PIN का उपयोग कर सकता है। पृष्ठ एक अलग सॉफ़्टवेयर सिमुलेशन भी देता है। दोनों में से कोई भी भुगतान नहीं भेजता या उत्पादन प्राधिकरण स्थापित नहीं करता।

अपने ब्राउज़र में कोई भी रसीद सत्यापित करें — उसे पेस्ट करें, कुछ भी अपलोड नहीं होता।

---

यह कैसे काम करता है — एक प्राधिकरण जीवनचक्र

स्वयं चलाएँ: node examples/crash-test.mjs — पूरी तरह ऑफ़लाइन, कोई API key नहीं।

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

अधिदेश। प्राधिकरण स्रोत सीमित काम परिभाषित करता है। यह ग्राहक-हस्ताक्षरित संचालन प्रोग्राम, सीमित क्षमता, आवश्यक मानवीय निर्णय, कोरम या मूल साक्ष्य का निर्भर-पक्ष संयोजन हो सकता है।

सटीक काम। Gate विधि, मूल स्थान, कॉल किए जाने वाले पक्ष, लक्ष्य, घटना और हर महत्वपूर्ण फ़ील्ड को कैनोनिकल निष्पादन योग्य ऑब्जेक्ट में बाँधता है। आशय, प्रॉम्प्ट या टिकट का पाठ वह ऑब्जेक्ट नहीं है।

सत्यापन, आरक्षण और प्रवेश। मूल आर्टिफ़ैक्ट मूल रूप में ही रहते हैं। निर्भर-पक्ष विश्वास और मैपिंग प्रोफ़ाइल पिन करता है, साक्ष्य की पूरी आवश्यकता का मूल्यांकन करता है, अलग स्थानीय प्राधिकरण निर्णय लेता है और क्रेडेंशियल-स्वामी एडेप्टर के प्रदाता में प्रवेश करने से पहले संबंधित प्राधिकरण आरक्षित करता है।

आवश्यक होने पर नया मानवीय प्राधिकरण। नीति में सटीक कार्रवाई और नियतात्मक प्रदर्शन हैश से बँधा WebAuthn/passkey निर्णय आवश्यक हो सकता है। इससे “आपने जो देखा, उसी पर हस्ताक्षर किए” के अंतर को कम किया जाता है; यह समझ, विवेक, वैधता या परिणाम साबित नहीं करता। एंटरप्राइज़ परिनियोजनों के लिए, Gate अतिरिक्त रूप से स्वतंत्र रूप से सत्यापित Authorization Server पुष्टि की आवश्यकता रख सकता है, जो उसी सटीक मानव साक्ष्य, उसी सटीक कार्रवाई, AS द्वारा वास्तव में देखे गए पहचान स्नैपशॉट और इच्छित Resource Server कुंजी से बंधी हो। स्नैपशॉट का समय और निर्भर पक्ष की अधिकतम आयु स्पष्ट हैं: नया टोकन पुराने डायरेक्टरी डेटा को वर्तमान नहीं बना सकता। AS चरण ग्राहक द्वारा पिन किए गए विश्वास के अंतर्गत साक्ष्य है; यह अपने आप में कभी प्राधिकरण नहीं देता, तत्काल रोज़गार स्थिति सिद्ध नहीं करता, और एजेंट ऑर्केस्ट्रेटर को प्राधिकरण का स्रोत नहीं बनाता।

सत्यनिष्ठ परिणाम। प्रवेश की अनुमति निष्पादन नहीं है, और निष्पादन प्रभाव नहीं है। हस्ताक्षरित रिकॉर्ड को ऑफ़लाइन सत्यापित किया जा सकता है; प्रदाता और प्रेक्षक के साक्ष्य अलग-अलग रहते हैं। खोया हुआ प्रतिसाद INDETERMINATE बन जाता है, जो समाधान की प्रतीक्षा वाली स्थिति है—पुनः प्रयास की अनुमति नहीं। उपचार एक नई अधिकृत कार्रवाई है और पुराने परिणाम को कभी नहीं बदलता।

---

डेवलपर इसका उपयोग क्यों करते हैं

पहले स्थानीय रूप से काम का मानचित्र बनाएँ, फिर MCP server या पतले SDK wrapper से एक घोषित कार्रवाई सतह को सुरक्षित करें। स्कैनर समीक्षा योग्य मानचित्र प्रस्तावित करता है; स्वामी अधिदेश परिभाषित करता है; Gate प्रदाता क्रेडेंशियल अपने पास रखता है और कवर किए गए पथ पर सटीक कार्रवाई लागू करता है। कोई भी स्कैन पूर्ण मध्यस्थता सिद्ध नहीं करता, और केवल खोज से कोई प्राधिकरण नहीं मिलता।

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

एजेंट को सीमित कार्य करने की क्षमता मिलती है, ऐसा स्थायी क्रेडेंशियल नहीं जिसे वह अपनी सुविधा से नए अर्थ दे सके।

---

उद्यमों को इसकी आवश्यकता क्यों है

एजेंट प्रक्रियाएँ पुनः आरंभ होती हैं और मॉडल बदलते हैं। ग्राहक का अधिदेश, उपभोग स्थिति, निरसन, अनिश्चितता और कार्य इतिहास उनसे बाहर बने रहने चाहिए। EMILIA इस टिकाऊ प्राधिकरण स्थिति को ग्राहक की सीमा पर बनाए रखता है और पिन किए गए अडैप्टरों के माध्यम से बाहरी प्रमाण स्वीकार करता है।

प्रबंधित Gate और Assurance Plane खुले प्रोटोकॉल के इर्द-गिर्द अधिदेश संचालन, एकीकरण, साक्ष्य संचालन, पुनः-प्रदर्शन, सहायता और सेवा स्तर जोड़ते हैं। ग्राहक प्राधिकरण, विश्वास मूल, क्रेडेंशियल, नीति और पोर्टेबल साक्ष्य पर नियंत्रण बनाए रखता है।

---

मानक

EMILIA Protocol खुला है और Apache-2.0 के अंतर्गत है। इसका मानक-निर्माण कार्य अलग-अलग Internet-Drafts के संग्रह के रूप में प्रकाशित है। प्रकाशित Internet-Draft, RFC नहीं होता, न ही अपनाया गया कार्य-समूह दस्तावेज़ या IETF का समर्थन; संशोधन और स्थिति के लिए Datatracker प्रामाणिक स्रोत है।

IANA पंजीकरण

दो पंजीकृत नाम EMILIA प्रारूपों के लिए कार्यान्वयनकर्ताओं को एक साझा संदर्भ देते हैं:

• application/vnd.emilia.authorization-evidence-challenge+json 6 अक्टूबर, 2026 को पंजीकृत किया गया था। यह प्रकाशित क्रमांकन विनिर्देश में परिभाषित सादा AE-CHALLENGE-v1 JSON ऑब्जेक्ट की पहचान करता है। HTTP अस्वीकृति प्रतिसाद अब भी application/problem+json का उपयोग करते हैं।
• canactid: 5 अक्टूबर, 2026 को अनंतिम रूप से पंजीकृत किया गया था। यह CAID-05 के अंतर्गत सटीक टाइप की गई कार्रवाइयों का नाम है। इसका संशोधित CRI स्कीम नंबर 1033 है।

ये पंजीकरण नामों और उनके विनिर्देशों को प्रकाशित करते हैं। ये IETF द्वारा अपनाए जाने, समर्थन, प्रमाणन या ग्राहक परिनियोजन को स्थापित नहीं करते।

एक परिणाम-सीमा सतह

वर्तमान प्रकाशित AEB-07, जो 2026-09-25 को एक व्यक्तिगत Internet-Draft के रूप में पोस्ट किया गया था और अपनाया नहीं गया, मूल निर्णय के बाद AEB को संयोजन बिंदु बनाता है। OAuth, AuthZEN, COAZ, AP2 और स्थानीय प्रणालियाँ अपने क्रेडेंशियल, संचालन मैपिंग और प्राधिकरण निर्णयों का स्वामित्व बनाए रखती हैं। AIMS (draft-ietf-wimse-aims) WIMSE कार्य-समूह का एक सूचनात्मक दस्तावेज़ है, जो WIMSE और OAuth जैसे मौजूदा मानकों की प्रोफ़ाइल बनाता है; यह स्वयं क्रेडेंशियल या निर्णय जारी नहीं करता। AEB संरक्षित प्रदाता सीमा पर मूल निर्णय लागू करता है: आवश्यकता पड़ने पर यह अंतिम कार्रवाई को बाँधता है, प्रत्येक अनुदान के लिए एक मूल पुनरावृत्ति-पहचान निकालता है, प्रदाता में प्रवेश से पहले आरक्षण करता है, पहले से जारी या अनिश्चित कार्रवाई के दौरान उसी कार्रवाई पर दूसरे प्रयास को अस्वीकार करता है, और प्रमाणित समाधान होने तक अनिश्चित परिणाम को लॉक रखता है।

CAID-05 का उपयोग तब किया जाता है जब स्वतंत्र रूप से एन्कोड किए गए निरूपणों की तुलना करनी हो। नए पहचानकर्ता IANA द्वारा अनंतिम रूप से पंजीकृत canactid: URI स्कीम का उपयोग करते हैं। यह पंजीकरण IETF द्वारा अपनाए जाने, समर्थन, प्रमाणन या स्थायी स्थिति का संकेत नहीं है। जब परिणाम का स्वामी PEP पहले से ही अंतिम संचालन पर वर्तमान निर्णय निकालता और लागू करता हो, तब CAID दूसरी अनिवार्य मैपिंग नहीं है। सटीक-कार्रवाई वाला प्लेग्राउंड आज़माएँ या CAID-04 से CAID-05 माइग्रेशन गाइड पढ़ें। AEC-06 का उपयोग तब किया जाता है जब निर्भर पक्ष को कई साक्ष्य चरणों की आवश्यकता हो। Authorization Receipts, Human Authorization Binding और Authority Introduction उन परिनियोजनों के लिए उपलब्ध प्रोफ़ाइल बने रहते हैं जिन्हें उनकी आवश्यकता है; हर AEB एकीकरण के लिए वे पूर्वापेक्षाएँ नहीं हैं। Architecture-03 नेविगेशन दस्तावेज़ बना रहता है।

परिणाम-प्रवेश मार्गदर्शिका कार्यान्वयन की सीमा और उन मामलों को बताती है जहाँ AEB अनावश्यक है। प्रत्यक्ष मूल हस्तांतरण प्रोफ़ाइल एक रिपॉज़िटरी कार्यान्वयन प्रोफ़ाइल है, जो दिखाती है कि मौजूदा अनुमति बिना दूसरी CAID या AEC परत के Gate तक कैसे पहुँचती है। AEB-07 बताता है कि ऐसा गेटवे हस्तांतरण किस बात की पुष्टि करता है और सीमा उसका सत्यापन कैसे करती है, लेकिन एन्कोडिंग को परिनियोजन पिन पर छोड़ता है; यह इस प्रोफ़ाइल के पिन किए गए स्नैपशॉट को एक सूचनात्मक संदर्भ एन्कोडिंग के रूप में उद्धृत करता है। सटीक रूप से प्रस्तुत -07 बाइट्स और उनका प्रकाशन रिकॉर्ड standards/staged/NEXT-AEB-07 में सुरक्षित रखे गए हैं।

सक्रिय संग्रह में Datatracker के 26 रिकॉर्ड हैं: एकल-लेखक के 21 रिकॉर्ड और सह-लेखक के पाँच रिकॉर्ड, जिनमें से प्रत्येक का अपना दायरा, संशोधन इतिहास और दर्ज रखरखाव स्थिति है। मानक मार्गदर्शिका, संग्रह और मशीन-पठनीय स्थिति सूची देखें।

IETF Internet-Drafts	वर्तमान स्थानीय स्नैपशॉट पथ: स्थिति सूची · एकल-लेखक पोस्ट की गई सूची · प्रामाणिक लाइव स्थिति: IETF Datatracker
बहु-भाषा सत्यापक	JavaScript · Python · Go — तीनों प्रतिपक्षी अनुरूपता वेक्टरों पर सहमत सिद्ध हुए हैं, हर push पर (npm run conformance)। एक टीम के पोर्टों के बीच संगति जाँच, स्वतंत्र रूप से निर्मित कार्यान्वयन नहीं। अलग से, विनिर्देश के आधार पर बाहरी लेखक द्वारा बनाया गया Rust कार्यान्वयन (स्रोत सार्वजनिक है) अपरिवर्तनीय स्रोत ट्री से मूल्यांकनकर्ता-नियंत्रित पुनर्निर्माण के अंतर्गत पिन किए गए 16-सूट/164-वेक्टर बंडल और पिन किए गए 359-केस शत्रुतापूर्ण अभियान में सफल होता है। रिपॉज़िटरी में शामिल निर्माण साक्ष्य अब भी कार्यान्वयनकर्ता द्वारा हस्ताक्षरित है, तृतीय-पक्ष द्वारा प्रमाणित नहीं (हस्ताक्षरित कथन); संशोधित तृतीय-पक्ष-प्रमाणित मेनिफ़ेस्ट और स्वतंत्र रूप से पिन की गई प्रमाणक कुंजी मिलने तक कठोर स्वतंत्र-निर्माण स्वीकृति लंबित है।
औपचारिक-मॉडल साक्ष्य	26 सीमित TLA+ सुरक्षा गुण अपनी कॉन्फ़िगर की गई अवस्था-सीमाओं में कायम रहे; यह कार्यान्वयन परिशोधन या असीमित प्रमाण नहीं है · चार मॉडलों में 35 Alloy तथ्य, 32 अभिकथन · दो संयोजित प्रतीकात्मक Dolev-Yao मॉडल, जो चुनौती, CAID, दो अनुमोदन, जारीकर्ता और प्राधिकरण पिन, रजिस्ट्री दृश्य, निरसन, उपभोग, निष्पादन और छह समर्पित दावे की सीमाओं को कवर करते हैं। Tamarin के बीस लेम्मा सत्यापित हैं — 17 सभी-ट्रेस दायित्व और 3 अस्तित्व-ट्रेस साक्षी; आठ जानबूझकर कमजोर किए गए रूप, भारवाही जाँच हटाने पर ठोस आक्रमण ट्रेस उत्पन्न करते हैं (formal/tamarin/).
MCP वितरण	npm पैकेज @emilia-protocol/mcp-server · आधिकारिक Registry प्रकाशन को MCP-REGISTRY.md में अलग से ट्रैक किया जाता है; एग्रीगेटर सूचियों का अनुमान इनमें से किसी स्थिति से नहीं लगाया जाता
लाइसेंस	Apache-2.0

एक ही टीम के तीन संदर्भ पोर्ट (JS / Python / Go) सभी 21 सूट और 340 वेक्टरों पर सहमत हैं। अलग से, बाहरी लेखक द्वारा बनाया गया Rust कार्यान्वयन पिन किए गए सार्वजनिक स्रोत ट्री से पुनर्निर्मित होकर पिन किए गए 16-सूट/164-वेक्टर स्वतंत्र-निर्माण बंडल और 359-केस शत्रुतापूर्ण अभियान में सफल होता है; हर बदलाव पर इसे अपनी CI लेन में फिर से चलाया जाता है। नए AEC स्वीकृति और चार-परिणाम समाधान सूट Rust के नाम नहीं किए गए हैं। यह बाहरी अंतर-संचालनीयता का साक्ष्य है, कठोर स्वतंत्र-निर्माण स्वीकृति नहीं; स्वतंत्र प्रमाणीकरण लंबित होने तक समेकित CI केस कठोर स्वीकृति की संख्या शून्य दर्ज करता है। CONFORMANCE.md देखें, या emiliaprotocol.ai/verify पर स्वयं किसी रसीद का सत्यापन करें।

---

प्राधिकरण स्टैक

परत	इसका कार्य
अधिदेश	मिशन, सीमाएँ, साक्ष्य, समाप्ति, प्रत्यायोजन और अपवाद नियम परिभाषित करता है।
CAID / सटीक कार्रवाई	जब प्राधिकरण और निष्पादन में स्वतंत्र रूप से एन्कोड किए गए निरूपण उपयोग हों, तब उनके महत्वपूर्ण अर्थ की तुलना करता है; यह प्राधिकरण नहीं देता।
AEC	आवश्यकता होने पर, यह मूल्यांकन करता है कि स्वतंत्र रूप से सत्यापित और मेल खाते साक्ष्य निर्भर पक्ष की बहु-चरणीय आवश्यकता पूरी करते हैं या नहीं; यह प्राधिकरण नहीं देता।
AEB / Gate	परिणाम-सीमा पर मूल या स्थानीय प्राधिकरण निर्णय लागू करता है, कवर किए गए प्राधिकरण को आरक्षित करता है और प्रदाता में प्रवेश नियंत्रित करता है।
परिणाम साक्ष्य	आह्वान, प्रदाता प्रतिसाद, देखा गया प्रभाव और अनिश्चितता को अलग-अलग रखता है।

---

प्रमाण बिंदु

मापदंड	मान
स्वचालित परीक्षण मामले	650+ फ़ाइलों में 10,700+; प्लेटफ़ॉर्म पर लागू सभी मामलों का सफल होना आवश्यक है
TLA+ सुरक्षा गुण	कॉन्फ़िगर की गई अवस्था-सीमा में 26 सीमित अपरिवर्तनीय गुण कायम रहे; यह कार्यान्वयन-परिशोधन या असीमित प्रमाण नहीं है — PROOF_STATUS.md देखें
Alloy संबंधपरक अभिकथन	चार मॉडलों में 35 तथ्य + 32 अभिकथन — CI में सत्यापित
सूचीबद्ध रेड-टीम मामले	86 — RED_TEAM_CASES.md
रिलीज़ सुरक्षा स्थिति	रिपॉज़िटरी सुरक्षा जाँचें सफल हैं; ऑडिट किए गए बदलावों पर Strix की हर खोज का प्रतिगमन कवरेज के साथ समाधान किया गया है और उसकी समीक्षा चर्चा पूरी की गई है
अनुरूपता (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
बहु-भाषा अनुरूपता	340 वेक्टर · 21 सूट: रसीदें · डिवाइस अनुमोदन · चार-परिणाम समाधान · बहु-पक्षीय कोरम · निरसन · Outcome Binding (अर्थगत + वास्तविक-क्रिप्टो) · Authority Document/Proof जारीकर्ता मिलान · समय-अभिप्रमाणन · विश्वास-रसीद (x2 प्रोफ़ाइल) · उद्गम · साक्ष्य-रिकॉर्ड · कैननिकलाइज़ेशन · सीमा · AEC स्वीकृति · मुद्रा · आरंभकर्ता-अभिप्रमाणन · उपभोग-प्रमाण · साक्षी · टाइमस्टैम्प-प्रमाण (RFC 3161)। JS / Python / Go सत्यापक सहमत हैं (node conformance/run.mjs)। बाहरी Rust आधाररेखा अब भी 164 वेक्टर / 16 सूट पर है। CONFORMANCE.md देखें।
हैंडशेक निर्माण p95	50 VUs पर 575ms — PERFORMANCE_PROOF.md

क्रिप्टोग्राफ़िक दीर्घायु (स्पष्ट परिनियोजन सीमाओं सहित)

वर्षों बाद सत्यापित किए जाने वाले साक्ष्य को उन एल्गोरिदमों से अधिक समय तक टिकना चाहिए जिनसे उस पर हस्ताक्षर किए गए थे। EP इसके लिए चार सीमित क्षमताएँ देता है, जिनमें से प्रत्येक की सटीक सीमा दावे का हिस्सा है:

• हाइब्रिड हस्ताक्षर (EP-RECEIPT-HYBRID-v1)। समान कैनोनिकल बाइट्स पर Ed25519 और ML-DSA-65, जिनमें आवश्यक एल्गोरिदम सेट को हस्ताक्षरित बाइट्स में प्रतिबद्ध किया जाता है, ताकि किसी एक हिस्से को हटाने पर बचा हुआ हस्ताक्षर अमान्य हो जाए। यह क्षमता डिप्लॉयमेंट में वैकल्पिक है; एक बार स्वीकृत दोहरे हस्ताक्षरकर्ता पंजीकृत हो जाए और नीति उसके PQ हिस्से की अनुमति दे, तो बिना पिन की गई Gate स्थिति डिफ़ॉल्ट रूप से दोहरे निर्गमन पर पहुँचती है। अन्यथा, यह स्पष्ट कारण के साथ केवल क्लासिकल मोड में रहती है। v1 सत्यापक हाइब्रिड रसीदों को स्वीकार करने के बजाय साफ़ तौर पर अस्वीकार करते हैं। बाहरी हस्ताक्षरकर्ता अनुबंध और AWS KMS अडैप्टर लागू किए गए हैं, लेकिन किसी सक्रिय AWS हस्ताक्षर कॉल, उत्पादन कुंजी, निर्भर-पक्ष सत्यापन या ML-DSA FIPS सत्यापन का दावा नहीं किया जाता। conformance/hybrid-receipts/ और lib/pq-custody-aws-kms.ts देखें।
• SCITT Signed Statement प्रोफ़ाइल (EP-SCITT-STATEMENT-v1)। EP रसीदों के लिए RFC 9943 Signed Statement का पूर्ण स्वरूप, जिसमें CWT Claims संरक्षित हेडर शामिल है। सीमा: किसी Transparency Service ने EP स्टेटमेंट स्वीकार नहीं किया है; बाहरी पंजीकरण एक अलग, नियंत्रित चरण है और ऐसा कोई चरण पूरा नहीं किया गया है। EP-RECEIPT-SCITT-PROFILE.md देखें।
• पुनः सत्यापन (EP-EVIDENCE-REATTESTATION-v1)। पुराने होते एल्गोरिदम के तहत हस्ताक्षरित साक्ष्य को उसके कमज़ोर पड़ने से पहले किसी मौजूदा एल्गोरिदम के तहत फिर से एंकर किया जा सकता है। सीमा: पुनः सत्यापन, समझौता होने से पहले होना चाहिए; यह बाद में साक्ष्य को ठीक नहीं कर सकता।
• FIPS डिप्लॉयमेंट मोड (EP-FIPS-MODE-v1)। क्लासिकल ऑपरेशनों को ऑपरेटर द्वारा दिए गए FIPS 140-3 सत्यापित प्रदाता के माध्यम से चलाता है; ML-DSA पथ के लिए स्पष्ट रूप से असत्यापित कार्यान्वयन की स्वीकृति आवश्यक है। सीमा: इससे "सत्यापित-प्रदाता डिप्लॉयमेंट मोड के साथ FIPS-आधारित एल्गोरिदम" का दावा किया जा सकता है और यह ऑपरेटर के प्रदाता तथा घोषित प्रमाणपत्र सीमा पर निर्भर करता है; यह व्यापक अनुपालन का दावा नहीं है, और यहाँ कुछ भी FIPS-सत्यापित नहीं है। FIPS-MODE.md देखें।

पूरे स्टैक में हाइब्रिड कार्यक्रम (हर आंतरिक हस्ताक्षर सतह) का मानचित्र pq-hybrid-program.md में दिया गया है और यह अभी पूरा नहीं हुआ है; पूरा होने तक पूरे स्टैक के बारे में कोई व्यापक दावा नहीं किया जाता।

---

मुख्य प्रोटोकॉल ऑब्जेक्ट

ऑब्जेक्ट	यह क्या है
प्राधिकरण कार्यक्रम / सीमित क्षमता	स्पष्ट दायरे, बजट या इकाइयों, समाप्ति, प्रत्यायोजन और उपभोग नियमों वाला सीमित अधिदेश।
CAID	नामित मैपिंग प्रोफ़ाइल के तहत किसी एक महत्वपूर्ण कार्रवाई के लिए कैनोनिकल पहचानकर्ता; मेल खाना प्राधिकरण नहीं है।
साक्ष्य आवश्यकता और AEC परिणाम	निर्भर-पक्ष का पिन किया हुआ नियम और उसका SATISFIED, UNSATISFIED, या INDETERMINATE मूल्यांकन।
AEB प्रवेश और अभिरक्षा रिकॉर्ड	प्राधिकरण, आरक्षण, प्रदाता में प्रवेश और मिलान स्थिति का निष्पादक-पक्ष रिकॉर्ड।
प्राधिकरण और परिणाम साक्ष्य	पोर्टेबल नेटिव या EP आर्टिफ़ैक्ट, जो अपने सटीक जारीकर्ता, दायरे और दावे की सीमा को बनाए रखते हैं।

---

त्वरित शुरुआत

1. सटीक स्थानीय गार्ड रनटाइम इंस्टॉल करें, फिर npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify चलाएँ और sendWire को किसी एक सटीक, घोषित महत्वपूर्ण टूल से बदलें।
2. जनरेट किए गए Authority Map, कार्रवाई मेनिफ़ेस्ट, महत्वपूर्ण फ़ील्ड, चुनी गई सीमा और नामित ब्लाइंड स्पॉट की समीक्षा करें।
3. अपरिवर्तित बाइट्स से केवल-मालिक के लिए हैंडऑफ़ और बिना सील वाला Lab कार्यक्षेत्र बनाने हेतु अलग --reviewed --crossing-profile <launch-profile> कमांड चलाएँ।
4. Gate को उस पथ पर इंस्टॉल करें जिसके पास प्रदाता क्रेडेंशियल और स्थायी उपभोग स्थिति का नियंत्रण है।
5. संचालन अधिदेश और नए मानव अनुमोदन या कोरम के लिए अपवाद नियम तय करें।
6. प्रवर्तन सक्षम करने से पहले अस्वीकृति, सटीक कार्रवाई, रीप्ले, टाइमआउट और मिलान के मामलों को चलाएँ।

90-सेकंड डेमो · त्वरित शुरुआत · एजेंट वॉकथ्रू · IETF ड्राफ़्ट · Discord

---

EP क्या है — और क्या नहीं

EMILIA स्वायत्त कार्य के लिए प्राधिकरण अवसंरचना है, पहचान प्रणाली, वॉलेट, प्रतिष्ठा स्कोर, निपटान रेल या सार्वभौमिक नीति इंजन नहीं।

• है: सीमित संचालन अधिदेशों, सटीक-कार्रवाई सत्यापन, स्थायी प्रवेश स्थिति, अनिश्चितता के ईमानदार निरूपण और कवर किए गए निष्पादक पथों पर पोर्टेबल साक्ष्य के लिए एक नियंत्रण तल।
• नहीं है: OAuth/OIDC, वर्कलोड पहचान या नीति इंजनों का विकल्प। ये निर्भर-पक्ष के पिन के तहत नेटिव इनपुट बने रहते हैं।
• नहीं है: हर कार्रवाई के लिए मानव अनुमोदन की आवश्यकता। कोई अधिदेश सीमित सीमाओं के भीतर स्वचालित कार्य की अनुमति दे सकता है और केवल सीमा पर नए प्राधिकरण की माँग कर सकता है।
• नहीं है: इस बात का प्रमाण कि प्रवेशित कार्रवाई सफलतापूर्वक निष्पादित हुई या उसका इच्छित प्रभाव पड़ा।
• नहीं है: मालिकाना प्रोटोकॉल नियंत्रण। कोर Apache-2.0 के अंतर्गत है और Internet-Drafts व्यक्तिगत प्रस्तुतियाँ हैं, RFC या IETF का समर्थन नहीं।

CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · तटस्थता प्रतिज्ञा