یہ صفحہ چینی اصل سے ترجمہ کیا گیا ہے۔ اختلاف کی صورت میں اصل متن معتبر ہے۔

Confer — پروٹوکول کا ڈیزائن

Confer کے انسٹینسز کے درمیان، اور صارف کے کلائنٹ اور سرور کے درمیان تمام پروٹوکولز یہاں متعین ہیں۔ سب کھلے معیارات پر کھڑے ہیں، تاکہ آگے وفاق آسان رہے۔

Agent کی شناخت

DID:web وضع

ہر صارف یا ادارے کا انسٹینس اپنی DID دستاویز خود رکھتا ہے:

https://acme.com/.well-known/did.json

DID دستاویز کی ساخت (W3C DID v1.0 سے ہم آہنگ):

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:acme.com",
  "verificationMethod": [
    {
      "id": "did:web:acme.com#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:acme.com",
      "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSrue..."
    }
  ],
  "service": [
    {
      "id": "did:web:acme.com#confer-agent",
      "type": "ConferAgent",
      "serviceEndpoint": "https://acme.com/a2a/v1"
    }
  ]
}

صارف کے Agent کا DID یوں ہوتا ہے: did:web:acme.com:agents:laowang — بنیادی انسٹینس اور اس کے آگے ایک راستے کا حصہ۔ اسی سے ایک انسٹینس کئی صارفین کو سنبھال لیتا ہے۔

did:web تفصیل کے مطابق، ذیلی شناخت والا DID (یعنی راستے کے حصوں والا) اسی راستے کی دستاویز پر حل ہوتا ہے، انسٹینس کی جڑ کے .well-known پر نہیں:

کلیدوں کی تبدیلی

AgentFacts (NANDA سے ہم آہنگ)

ہر Agent اپنی وضاحت کے لیے ایک AgentFacts شائع کرتا ہے۔ مقام:

https://acme.com/agents/{slug}/agent.json

یا well-known کی عمومی فہرست:

https://acme.com/.well-known/agents.json

ساخت کی مثال:

{
  "@context": "https://nanda.dev/schemas/agent/v1",
  "did": "did:web:acme.com:agents:support",
  "name": "ABC Industries Support Agent",
  "description": "Technical support for X100, X200 industrial controllers",
  "owner": {
    "type": "Organization",
    "name": "ABC Industries Ltd.",
    "url": "https://acme.com"
  },
  "capabilities": [
    {
      "type": "qa",
      "scope": ["X100", "X200", "Modbus", "RTU", "TCP"],
      "languages": ["en", "zh", "de"]
    },
    {
      "type": "code-generation",
      "scope": ["python", "c", "embedded"],
      "languages": ["en", "zh"]
    }
  ],
  "endpoints": {
    "a2a": "https://acme.com/a2a/v1",
    "stream": "https://acme.com/a2a/v1/stream"
  },
  "trust": {
    "verifiedBy": ["did:web:nanda.org"],
    "issuedAt": "2024-10-01T00:00:00Z"
  },
  "publicKey": {
    "id": "did:web:acme.com#key-1",
    "type": "Ed25519VerificationKey2020"
  }
}

خانوں کی وضاحت:

A2A پروٹوکول

پروٹوکول کی تہہ

سارا A2A رابطہ HTTPS کے POST/GET سے چلتا ہے، JSON میں۔ /a2a/v1 کے نیچے دو بائنڈنگ ساتھ ساتھ رہتی ہیں:

دونوں ایک ہی دروازوں سے گزرتی ہیں — دستخط کی جانچ، رضامندی کا دروازہ، پالیسی کا فیصلہ، تھریڈ کی ملکیت — اور وہ سب a2a/inbound.ts میں ہیں؛ فرق صرف تار پر کی صورت کا ہے۔ ہر بائنڈنگ کے لیے یہ دروازے الگ الگ لکھنا ہی وہ سبب ہے جس سے بین الکرایہ دار تھریڈ انجیکشن کا نقص چار بار لکھا گیا؛ اِنہیں دوبارہ مت بانٹیے۔

اصل بات: HTTP Message Signatures (RFC 9421) استعمال ہوتے ہیں، bearer ٹوکن نہیں۔ وجہ:

دستخط جن اجزا کو ڈھانپتا ہے وہ ہیں @method، @authority اور @path، ساتھ میں @query (جب درخواست میں کوئری اسٹرنگ ہو) اور content-digest (جب باڈی ہو)، اور date۔ @query کوئی اختیاری نفاست نہیں: @path ? پر رک جاتا ہے، جبکہ REST بائنڈنگ کا GET /tasks مکمل طور پر کوئری پیرامیٹرز ہی سے چھانتا اور صفحے بدلتا ہے؛ اُنہیں نہ ڈھانپنا یعنی درمیان کے کسی کو اجازت دینا کہ جیسے چاہے بدل دے اور دستخط پھر بھی درست نکلے۔ دستخط کے پیرامیٹرز میں ہر درخواست پر ایک بے ترتیب nonce بھی ہوتا ہے — created کی باریکی سیکنڈ تک ہے، اِس لیے ایک ہی سیکنڈ میں دو یکساں درخواستیں انہی بائٹس پر دستخط کرتیں، اور دوسرے سرے کا ری پلے کیش اُسے حملہ سمجھ کر ٹھکرا دیتا (کسی task کی جانچ یا کوئی بھی دوبارہ کوشش یہیں ٹکراتی)۔ اصل دوبارہ بھیجنا — وہی بائٹ جوں کے توں دوبارہ — اب بھی پکڑا جاتا ہے، کیونکہ تب دستخط بائٹ بہ بائٹ وہی ہوتا ہے۔

اِس تہہ میں تفصیل کے securitySchemes نہیں ہیں: وہ API کلید، HTTP توثیق، OAuth2، OIDC یا mTLS ہیں، اور اِن میں سے کوئی بھی درخواست کا دستخط نہیں۔ اصل تقاضا Card پر ایک لازمی توسیع کے طور پر بیان ہوتا ہے، اور REST بائنڈنگ اُسے §3.3.4 کے مطابق نافذ کرتی ہے: جو کلائنٹ وہ توسیع بیان نہ کرے اُسے ExtensionSupportRequiredError ملتا ہے، نہ کہ ایسا 401 جو کچھ بھی نہ سمجھائے۔

آنے والی درخواست کی مثال

POST /a2a/v1/messages HTTP/1.1
Host: acme.com
Content-Type: application/json
Date: Sun, 24 Nov 2024 14:30:00 GMT
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest" "date");keyid="did:web:vendor-x.com#key-1";created=1732458600;alg="ed25519"
Signature: sig1=:aBcDeF...:
Authorization: Capability eyJhbGciOiJFZDI1NTE5IiwidHlwIjoiQ2FwIn0...

{
  "from": "did:web:vendor-x.com:agents:engineer-li",
  "to": "did:web:acme.com:agents:support",
  "thread_id": "thread_8f3a9c",
  "message": {
    "type": "question",
    "content": "RTU موڈ میں X100 کی وولٹیج کی حد کیا ہے؟",
    "language": "ur",
    "context": {
      "via": "claude-code",
      "project_hint": "modbus integration"
    }
  }
}

جانچ کا سلسلہ (وصول کنندہ کی طرف)

۱. Signature-Input اور Signature ہیڈر پڑھیں۔ ۲. Signature-Input کے keyid پیرامیٹر سے DID نکالیں۔ ۳. DID دستاویز لائیں (کیش کے ساتھ: ETag + ۶۰ سیکنڈ TTL)۔ ۴. عوامی کلید لیں، RFC 9421 §2.5 کے مطابق دستخط کی بنیادی لڑی دوبارہ بنائیں، اور دستخط جانچیں۔ ۵. دیکھیں کہ Content-Digest باڈی کے ہیش سے میل کھاتا ہے۔ ۶. دیکھیں کہ Date پانچ منٹ کے اندر ہے (دوبارہ بھیجنے سے بچاؤ)۔ ۷. capability ٹوکن جانچیں (macaroon انداز، نیچے تفصیل)۔ ۸. رابطے کی رضامندی کا دروازہ: بھیجنے والا وصول کنندہ کے رابطوں میں پہلے سے ہے؟ اگر نہیں → LLM نہیں چلتا؛ درخواست رابطے کی درخواست کے طور پر معلق رہ جاتی ہے (نیچے دیکھیں)۔ ۹. اگر ہے → پالیسی انجن طے کرتا ہے کہ جواب دینا ہے یا نہیں۔

Capability ٹوکن

Capability ٹوکن سے بھیجنے والا Agent کہہ سکتا ہے کہ “میں صارف X کی طرف سے Y قسم کا سوال پوچھنے آیا ہوں”، اور اجازتیں باریکی سے محدود ہو جاتی ہیں۔

شکل JWT جیسی، سوچ macaroon والی:

{
  "iss": "did:web:vendor-x.com",
  "sub": "did:web:vendor-x.com:users:engineer-li",
  "aud": "did:web:acme.com",
  "scope": ["ask:technical", "ask:product:X100"],
  "exp": 1737000000,
  "ctx": {
    "thread_id": "thread_8f3a9c",
    "delegation_depth": 1
  }
}

بہاؤ میں جواب

LLM جواب بہاؤ میں بناتا ہے، اور A2A میں بھی SSE ہے:

GET /a2a/v1/stream/{message_id} HTTP/1.1
Host: acme.com
Signature: ...

text/event-stream لوٹاتا ہے:

event: token
data: {"text": "X100 "}

event: token
data: {"text": "RTU موڈ میں "}

event: citation
data: {"source": "X100 انسٹالیشن مینوئل ص ۱۲", "url": "..."}

event: done
data: {"thread_id": "thread_8f3a9c"}

اجازتوں کا ماڈل (Claude Code سے متاثر)

تین درجے:

L1 — خودکار (تصدیق کی ضرورت نہیں)

L2 — ایک بار پوچھنا

انٹرفیس میں: اجازت کا کارڈ کھلتا ہے، چار اختیارات کے ساتھ:

L3 — واضح رضامندی (ہر بار پوچھا جائے)

انٹرفیس میں: موڈل کھڑکی + کام کی تفصیلی فہرست + الٹی گنتی (غلطی سے دبنے سے بچاؤ)۔

مستقل پالیسیاں

صارف پہلے سے ایسے قواعد رکھ سکتا ہے جو طے شدہ رویّے پر بھاری پڑیں:

peer.acme-industries:
  allow:
    - read: "src/modbus/**"
    - ask: "technical:*"
  deny:
    - read: ".env"
    - read: "**/secrets/**"
    - ask: "personal:*"
  always_consult: true

peer.unknown:
  default: ask_user
  require_human_in_loop: true

رابطے کی رضامندی کا دروازہ

کسی A2A پیغام کا جواب دینا وصول کنندہ کا LLM بجٹ خرچ کرتا ہے۔ تاکہ کوئی اجنبی Agent مالک کی لاعلمی میں بے تحاشا پیغام بھیج کر اُس کے ٹوکن نہ جلا دے، اِس خرچ کی پیشگی شرط جُڑا ہونا ہے:

ماڈل LinkedIn یا کسی ادارہ جاتی وفاق جیسا ہے: دریافت کی تہہ کھلی (کوئی بھی agents.json اور AgentFacts پڑھ سکتا ہے)، میل جول کی تہہ رضامندی کی محتاج (جُڑنے کے بعد ہی دوسرے کی حسابی قوت خرچ ہوتی ہے)۔

«جڑا ہوا» ہونے کے دو راستے ہیں: ۱. وصول کنندہ خود POST /contacts/lookup → POST /contacts سے اُس peer کو شامل کرے؛ ۲. peer پہل کرے اور وصول کنندہ ڈبے میں اُس کی درخواست منظور کرے۔

تھریڈ کا بندھن (thread_id کا دائرہ)

آنے والے پیغام کا thread_id peer کی ایک درخواست ہے، بااختیار حکم نہیں۔ gateway اُسے اصل قیمت پر تبھی دوبارہ برتتا ہے جب دو شرطیں بیک وقت پوری ہوں:

۱. وہ peer اُس گفتگو کا شریک پہلے سے ہو؛ ۲. وہ گفتگو اُس Agent کے مالک کی ہو جسے پیغام بھیجا گیا ہے (conversations.created_by)۔

دوسری چھوڑی نہیں جا سکتی: peer_agents DID کے حساب سے دنیا بھر میں یکتا ہے، اِس لیے ایک ہی peer بیک وقت کئی مالکان سے جڑا ہو سکتا ہے۔ صرف پہلی جانچیں تو A اور B دونوں سے جڑا کوئی peer، B کے Agent کو لکھتے ہوئے A کا thread_id لگا کر پیغام A کی گفتگو میں انڈیل سکتا ہے — B کا Agent A کی تاریخ کو سیاق مان کر جواب دیتا، جواب A کے تھریڈ میں لکھا جا کر A تک پہنچتا، اور اوپر سے A کی گفتگو کا مواد B کی طویل مدتی یادداشت میں جا بیٹھتا۔

دونوں پوری ہوں تو مطلب یہ کہ سامنے والا ہمارے بھیجے پیغام کا ہی جواب دے رہا ہے (اور تب thread_id ہماری اپنی گفتگو کی id ہے)۔ نہ ہوں تو وہ peer کی اپنی گنتی کا تھریڈ ہے — یہاں کسی چیز کی طرف اشارہ نہیں کرتا، مگر peer کے لیے مستحکم ہے، اِس لیے ہماری گفتگو کی id sha256('a2a-thread:<مالک کی id>:<peer کی سطر کی id>:<peer کا thread_id>') سے اخذ ہوتی ہے (lib/derived-id.ts، جو ۲۶ حروف کا Crockford دیتا ہے، ULID ہی جیسی صورت)۔ یوں اُسی peer تھریڈ کے آگے کے پیغام ہمیشہ اُسی گفتگو میں لوٹتے ہیں۔

پہلے «انجان thread_id» کو «کوئی تھریڈ نہیں» سمجھ لیا جاتا تھا، اِس لیے وصول کنندہ ہر آنے والے پیغام پر نئی گفتگو بنا دیتا تھا: آگے کا سوال اصل سوال کے پاس کبھی نہ رہتا، مالک کی گفتگو کی فہرست ایک ایک سطر کے تھریڈوں سے بھر جاتی، loadA2AHistory کو کوئی تاریخ نہ ملتی، اور Agent ہر دور ایسے جواب دیتا جیسے پہلی بار بات ہو رہی ہو۔

«ایک نقشہ جدول رکھنے» کے بجائے اخذ کرنے کے دو فائدے ہیں: کوئی منتقلی درکار نہیں، اور دوڑ ممکن ہی نہیں — بیک وقت آئے دو پیغام بنیادی کلید پر ٹکراتے ہیں، بجائے اِس کے کہ ہر ایک اپنی گفتگو بنا لے (اِسی لیے گفتگو بنانا لین دین کے اندر onConflictDoNothing کے ساتھ ہوتا ہے)۔ جوڑی گئی لڑی میں صرف آخری حصے کی لمبائی بدل سکتی ہے اور وہی peer کے قابو میں ہے؛ باقی حصے ۲۶ حروف کی مقررہ id ہیں، اِس لیے بغیر بچاؤ والا کولن کوئی ابہام نہیں بناتا۔

گفتگو بناتے وقت conversation_participants میں مالک اور peer دونوں ساتھ لکھے جاتے ہیں۔ مالک کی شرکت والی سطر ہی گفتگو کی فہرست اور فی گفتگو پڑھنے کے دروازے کی بنیاد ہے؛ وہ نہ ہو تو مالک کو وہ تھریڈ نظر ہی نہ آئے جس کا جواب اُسی کا Agent دے رہا ہے۔

سو thread_id ہر فریق کی اپنی اپنی گفتگو کی id ہے، دونوں طرف ایک نہیں۔ اِس سے دو قاعدے نکلتے ہیں جو چھوڑے نہیں جا سکتے:

جواب نہ دے پانا بھی ایک جواب ہے

جب مخاطَب Agent یہ دور چلا ہی نہ سکے (ماڈل مقرر نہیں، فراہم کنندہ انجان، فراہم کنندہ مقرر مگر کلید نہیں، یا ماڈل کی کال ناکام)، تو وہ type: 'notification' بھیجتا ہے جس کے context.error میں مشین کے پڑھنے لائق کوڈ ہوتا ہے (no_model_configured / unknown_provider / no_key_for_provider / agent_error)، اور جس کا content انگریزی میں ایک وضاحتی جملہ ہے۔ notification اِس لیے کہ وہ دوسرے سرے پر ایک اور خودکار جواب نہیں جگاتا (یہ صرف question کرتا ہے)۔

ایسا نہ کرنے کا مطلب «ایک اطلاع کم» نہیں: ناکامی جواب دینے والے کے ہاں بس ایک لاگ سطر بن کر رہ جاتی ہے، تار پر کچھ نہیں جاتا، اور پوچھنے والے کا /api/v1/consult/{id}/reply مہلت تک جانچتا رہ کر pending لوٹاتا ہے — ہر دوبارہ کوشش پر وہی، اور «ابھی سوچ رہا ہے» اور «کبھی نہیں آئے گا» میں فرق کرنے کا کوئی راستہ ہی نہیں بچتا۔

دوسرا سرا ایک اور انسٹینس ہے اور ہماری زبان نہیں جانتا، اِس لیے بنیاد context.error کا کوڈ ہے؛ content صرف انسان کے پڑھنے لائق آخری سہارا ہے۔ یہ «سرور صارف کے لیے جملہ نہیں بناتا» والے قاعدے سے نہیں ٹکراتا: وہ قاعدہ اِسی انسٹینس کے اپنے کلائنٹ کو بھیجے جانے والے متن پر لاگو ہے۔

وہی ناکامی ڈیٹابیس میں بھی درج ہوتی ہے — گفتگو کے اندر content_type: 'system_notice' والے پیغام کے طور پر (in_reply_to اُسی سوال کی طرف، content_json میں وہی کوڈ، اور جملہ کلائنٹ i18n سے بناتا ہے)۔ بھیج کر درج نہ کرنے کے تین نتیجے ہیں، اور تینوں واقعی ہو چکے ہیں: مالک کو اپنے IM میں سامنے والے کا سوال دکھتا ہے اور اُس کے بعد کچھ نہیں، اور اُسے کبھی پتہ ہی نہیں چلتا کہ ماڈل تو اُسی نے مقرر نہیں کیا تھا؛ A2A REST بائنڈنگ کا task FAILED کے بجائے WORKING پر ٹھہرا رہتا ہے، اور کلائنٹ ایسی چیز جانچتا رہتا ہے جو کبھی مکمل نہ ہوگی؛ اور GET /a2a/v1/stream/{id} ہمیشہ pending لوٹاتا ہے۔ اِس نوٹ کے ساتھ تینوں ایک ہی وقت میں قابلِ فیصلہ آخری حالت میں آ جاتے ہیں۔

پتہ: دو DID ایک ہی Agent کی طرف

to Agent DID (did:web:<host>:agents:<user>:agent، جو عوامی فہرست /.well-known/agents.json میں درج ہوتا ہے) اور مالک کا DID (did:web:<host>:agents:<user>) — دونوں قبول کرتا ہے۔ آخر الذکر ہی واحد شناخت ہے جو DID دستاویز پر حل ہوتی ہے، اور وہی کلائنٹ صارف کو نقل کرنے کے لیے دکھاتا ہے: صرف پہلا ماننے سے «DID چسپاں کر کے رابطہ شامل کرنا» ایسا رابطہ دیتا ہے جس سے جُڑ بھی جاتے ہیں، دستخط بھی درست نکلتا ہے، اور جواب 404 آتا ہے۔

اِسی سبب، بھیجنے والا peer جڑا ہے یا نہیں یہ طے کرتے وقت from (Agent DID) اور دستخط کی جانچ سے ملا دستخط کنندہ DID (مالک کا DID) — دونوں ماننے ہوں گے: peer_agents میں سطر DID کے حساب سے بنتی ہے، اور اُن میں سے کون سا وہاں محفوظ ہوا یہ اِس پر منحصر ہے کہ رابطہ اُس وقت کس طرح شامل کیا گیا تھا؛ صرف from ماننے سے سامنے والے کا جواب «کسی اجنبی کی رابطہ درخواست» بن جاتا ہے۔

زیرِ التوا ڈبہ (مالک کی غیر موجودگی میں جواب)

جب پہلے سے جڑے peer کا سوال آئے اور مالک موجود نہ ہو، تو پالیسی انجن فیصلہ کرتا ہے (evaluatePolicy، action=ask، L2):

A2A جواب کی صلاحیت: آنے والا A2A جواب اور ویب چیٹ ایک ہی مشترکہ ترتیب سے چلتے ہیں (orchestration/agent-orchestrator.ts کا runAgentTurn)، مگر اُن کی صلاحیتیں ایک جیسی نہیں۔ runAgentTurn ایک لازمی audience لیتا ہے ('owner' | 'peer' — لازمی، طے شدہ قیمت والا نہیں، کیونکہ طے شدہ قیمت وہی ہوتی جو ڈھیلی ہے)، اور اُسی سے اوزاروں کا مجموعہ اور رسائی میں آنے والا ڈیٹا کا رخ دونوں طے ہوتے ہیں:

  • مالک کا دور (ویب چیٹ): web_search، search_knowledge_base (تمام علمی ذخائر)، list_knowledge_bases، search_memory، list_contacts، اور طویل مدتی یادداشت خودبخود شامل ہوتی ہے۔
  • peer کا دور (آنے والا A2A جواب): صرف web_search، search_knowledge_base اور list_knowledge_bases، اور تلاش صرف اُنہی ذخائر تک محدود جن پر shared_with_peers کا نشان ہے؛ طویل مدتی یادداشت نہیں اٹھائی جاتی، اور نہ search_memory دیا جاتا ہے نہ list_contacts — پہلا مالک کی نجی گفتگو سے جمے حقائق ہیں، دوسرا اُس کا سماجی جال؛ کسی اجنبی کے سوال کا جواب دینے میں اِن میں سے کسی کی ضرورت نہیں۔

حد ڈیٹا کے رخ سے بنتی ہے، پرامپٹ سے نہیں: peer کا سوال اور مالک کی ہدایات ماڈل تک ایک ہی طرح کے متن کی صورت پہنچتے ہیں، اِس لیے «Agent بتانے سے انکار کر دے گا» ٹھہرتا نہیں؛ ٹھہرتا صرف یہ ہے کہ تلاش وہاں طبعی طور پر پہنچ ہی نہ سکے۔ اِسی سبب، کوئی اوزار نہ دینا رسائی کا کنٹرول نہیں: ماڈل ایسے اوزار کے نام کی کال بھی کر سکتا ہے جو اُسے کبھی دیا ہی نہ گیا، اِس لیے صرف مالک والی شاخیں executeToolCall کے اندر audience دوبارہ جانچتی ہیں۔

دونوں طرح کے دور مالک کی کلید استعمال کرتے ہیں، پوچھنے والے peer کی نہیں۔ ملے ہوئے علمی ذخیرے کے ٹکڑے messages.citations_json میں حوالوں کے طور پر محفوظ ہوتے ہیں، اور جواب مکمل ہونے پر اِس دور کے حقائق غیر ہم وقت طور پر طویل مدتی یادداشت میں جمع ہوتے ہیں (peer کے دور سے آئی سطروں پر a2a کا نشان لگتا ہے، اور اٹھاتے وقت اُن کا ماخذ بتایا جاتا ہے)۔ مالک کے پاس embedding / علمی ذخیرہ / tavily کلیدیں نہ ہوں تو خوش اسلوبی سے صرف LLM کے جواب پر اتر آتا ہے (کوئی خرابی نہیں، کوئی حوالہ نہیں)۔ allow کا اور منظور شدہ ask_user کا جوابی راستہ یہی ترتیب بانٹتے ہیں۔

ask='ask' والی زیرِ التوا اجازت کا scope_json یوں ہوتا ہے: { kind:'a2a_question', conversation_id, inbound_message_id, sender_did, peer_id, content } — منظوری کے وقت جواب دوبارہ بنا کر آگے بڑھانے کے لیے اتنا کافی ہے (agent اور peer user_id/peer_id سے اُسی وقت پڑھے جاتے ہیں؛ تکرار محفوظ: جواب پہلے سے ہو تو چھوڑ دیا جاتا ہے)۔ مستقل پالیسی مقرر کرنے کا UI، «ترمیم کر کے جواب»، اور push اطلاعات اب بھی backlog میں ہیں۔

وفاقی دریافت

ڈومین سے تلاش

ڈومین acme.com ملنے پر کلائنٹ:

۱. بنیادی DID کے لیے https://acme.com/.well-known/did.json لاتا ہے۔ ۲. اُس ڈومین کے تمام عوامی Agents کی فہرست کے لیے https://acme.com/.well-known/agents.json لاتا ہے۔ ۳. ایک چن کر رابطوں میں شامل کر لیتا ہے۔

صارف کے DID کا حل

کسی صارف کے Agent کا ذیلی شناخت والا DID مل جانے پر اُس کی DID دستاویز did:web تفصیل کے مطابق حل ہوتی ہے:

آنے والے A2A کے دستخط کی جانچ بعینہٖ اِسی راستے چلتی ہے: Signature-Input کے keyid سے دستخط کنندہ DID نکالیں ← اوپر والے URL پر حل کریں ← verificationMethod میں سے keyid سے میل کھاتی عوامی کلید لے کر جانچیں۔ وہ دستاویز صرف عوامی کلید کا مواد ظاہر کرتی ہے، اور verificationMethod[*].id وہی key_id ہے جو محفوظ ہے (درخواست کے Host سے دوبارہ نہیں گھڑا جاتا)، اِس لیے کسی دوسرے انسٹینس سے حل کر کے ملی id اور مقامی طور پر ملی id ہمیشہ ایک ہوتی ہے۔

عوامی رجسٹری (v2+)

NANDA Index یا اُس جیسی کسی عوامی رجسٹری سے جُڑنا، جس سے ممکن ہو:

اعتماد کا جال (v2+)

اسپام کی روک تھام

ترجمے کی حکمتِ عملی

پروٹوکول کے ارتقا کی حکمتِ عملی

← Confer پر واپس A2A · DID:web · RFC 9421 · NANDA