سبق کا ویڈیو دیکھیں: کرپٹو گرافک رسیدوں کے ساتھ AI ایجنٹس کو محفوظ کرنا
(سبق کا ویڈیو اور تھمب نیل مائیکروسافٹ کے مواد کی ٹیم مرجر کے بعد شامل کرے گی، سبق 14 / 15 کے سانچے سے میل کھاتے ہوئے۔)
یہ سبق مندرجہ ذیل کو شامل کرے گا:
اس سبق کو مکمل کرنے کے بعد، آپ جان پائیں گے کہ کیسے:
تصور کریں کہ آپ نے Contoso Travel کے لیے ایک AI ایجنٹ تعینات کیا ہے۔ ایجنٹ کسٹمر کے درخواستیں پڑھتا ہے، فلائٹس API کو کال کر کے آپشنز دیکھتا ہے، اور کسٹمر کی جانب سے سیٹ بک کرتا ہے۔ پچھلے سہ ماہی میں، ایجنٹ نے 50,000 بکنگز کیں۔
آج ایک آڈیٹر آتا ہے۔ وہ ایک سادہ سوال کرتا ہے: “مجھے دکھائیں کہ آپ کے ایجنٹ نے کیا کیا۔”
آپ لاگ فائلز حوالے کرتے ہیں۔ آڈیٹر انہیں دیکھتا ہے اور مشکل سوال پوچھتا ہے: “میں کیسے جانوں کہ یہ لاگز ایڈیٹ نہیں کیے گئے؟”
یہ آڈٹ ٹریل کا مسئلہ ہے۔ آج کل اکثر ایجنٹ تعیناتیاں ان پر انحصار کرتی ہیں:
ان میں سے کوئی بھی آڈیٹر کے سوال کا جواب نہیں دے سکتا بغیر آڈیٹر کے کسی پر اعتماد کے (آپ، آپ کا کلاؤڈ فراہم کنندہ، آپ کے ڈیٹا بیس فروشندہ)۔ داخلی استعمال کے لیے یہ اعتماد اکثر قابل قبول ہوتا ہے۔ مالیات، صحت کی دیکھ بھال، EU AI ایکٹ کے تحت کاموں کے لیے ایسا نہیں۔
کرپٹو گرافک رسیدیں اس مسئلے کو اس طرح حل کرتی ہیں کہ ہر ایجنٹ کی کارروائی آزادانہ طور پر تصدیق کی جا سکتی ہے۔ آڈیٹر کو آپ پر اعتماد کرنے کی ضرورت نہیں۔ انہیں صرف آپ کی عوامی کلید اور رسید خود چاہیے۔
رسید ایک JSON آبجیکٹ ہے جو ریکارڈ کرتا ہے کہ ایجنٹ نے کیا کیا، اور اسے ڈیجیٹل دستخط کے ساتھ دستخط کیا گیا ہے۔
flowchart LR
A[ایجنٹ ایک آلہ چلاتا ہے] --> B[رسید کا مواد تیار کریں]
B --> C[جے ایس او این آر ایف سی 8785 کو معیاری بنائیں]
C --> E[ایڈ25519 سے معیاری بائٹس پر دستخط کریں]
E --> F[دستخط کے ساتھ رسید]
F --> G[آڈیٹر آف لائن تصدیق کرتا ہے]
G --> H{دستخط درست ہے؟}
H -- yes --> I[چھیڑ چھاڑ کی ثبوت]
H -- no --> J[رسید مسترد ہو گئی]
ایک کم از کم رسید اس طرح دکھائی دیتی ہے:
{
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": "sha256:a3f9c1...",
"result_hash": "sha256:7b2e1d...",
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 47,
"previous_receipt_hash": "sha256:9d4e6a...",
"signature": {
"alg": "EdDSA",
"sig": "c5af83...",
"public_key": "8f3b2c..."
}
}
تین خصوصیات کام کر رہی ہیں:
دستخط۔ رسید ایجنٹ کے گیٹ وے کے ذریعے Ed25519 پرائیویٹ کی سے دستخط کی جاتی ہے۔ جس کے پاس متعلقہ عوامی کلید ہو، وہ اس دستخط کو آف لائن ویریفائی کر سکتا ہے۔ کسی بھی فیلڈ میں چھیڑچھاڑ دستخط کو غیر معتبر بنا دیتی ہے۔
کینونیکل انکوڈنگ۔ دستخط کرنے سے پہلے، رسید کو JSON Canonicalization Scheme (JCS, RFC 8785) استعمال کرتے ہوئے سیریلائز کیا جاتا ہے۔ یہ یقینی بناتا ہے کہ دو الگ الگ امپلیمنٹیشنز جو ایک ہی منطقی رسید پیدا کرتے ہیں، ایک جیسا بائٹ-شناسا نتیجہ پیدا کریں۔ بغیر کینونیکلائزیشن کے، مختلف JSON سیریلائزرز ایک ہی مواد کے لیے مختلف دستخط پیدا کریں گے۔
ہیش چیننگ۔ previous_receipt_hash فیلڈ ہر رسید کو اس سے پہلے والی رسید سے جوڑتا ہے۔ ایک رسید کو ہٹانے یا ترتیب بدلنے سے ہر بعد کی رسید خراب ہو جاتی ہے۔ چھیڑ چھاڑ چین کی سطح پر بھی نظر آتی ہے چاہے انفرادی دستخط چوری کر لیے جائیں۔
یہ خصوصیات مل کر تین ضمانتیں فراہم کرتی ہیں:
رسید بنانے کے لیے آپ کو کوئی خاص لائبریری درکار نہیں۔ کرپٹو گرافک پرائمیٹوز عام دستیاب ہیں اور منطق چند درجن Python لائنز ہے۔
code_samples/18-signed-receipts.ipynb میں ہاتھ سے کرنے کی مشقیں پورے عمل کو قدم بہ قدم دکھاتی ہیں۔ خلاصے کا ورژن:
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # آر ایف سی ۸۷۸۵ کینونیکل جے ایس او این
def b64url_nopad(data: bytes) -> str:
return base64.urlsafe_b64encode(data).decode("ascii").rstrip("=")
def sha256_canonical(obj) -> str:
"""SHA-256 of a Python object's JCS-canonical JSON form."""
return f"sha256:{hashlib.sha256(canonicalize(obj)).hexdigest()}"
# ایک دستخطی کلید پیدا کریں یا لوڈ کریں (پیداوار میں، کلید کے خزانے میں محفوظ کریں)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# رسید کا مواد تیار کریں (ابھی کوئی دستخط نہیں)
tool_args = {"origin": "SYD", "destination": "LAX"}
tool_result = [{"flight": "QF11", "price": 1850, "stops": 0}]
payload = {
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": sha256_canonical(tool_args),
"result_hash": sha256_canonical(tool_result),
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 0,
"previous_receipt_hash": None,
}
# جے سی ایس بائٹس کو براہ راست معیاری بنائیں اور دستخط کریں۔ پیور ایڈ ڈی ایس اے اندرونی طور پر ہیشز کرتا ہے۔
canonical_bytes = canonicalize(payload)
signature_bytes = signing_key.sign(canonical_bytes).signature
# ایک منظم دستخطی آبجیکٹ منسلک کریں۔
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
یہی مکمل دستخط کا عمل ہے۔ نوٹ بک میں مشقیں ہر قدم کی وضاحت کرتی ہیں۔
تصدیق الٹی کارروائی ہے:
import base64
import hashlib
from nacl import signing
from nacl.exceptions import BadSignatureError
from jcs import canonicalize
def b64url_decode(s: str) -> bytes:
padding = "=" * ((4 - len(s) % 4) % 4)
return base64.urlsafe_b64decode(s + padding)
def verify_receipt(receipt: dict) -> bool:
# دستخط ایک منظم شے ہے: {"alg", "sig", "public_key"}۔
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# اصل میں دستخط کیے گئے پے لوڈ کو پھر سے تعمیر کریں (دستخط کو چھوڑ کر سب کچھ)۔
payload = {k: v for k, v in receipt.items() if k != "signature"}
canonical_bytes = canonicalize(payload)
try:
verify_key = signing.VerifyKey(b64url_decode(sig_obj["public_key"]))
verify_key.verify(canonical_bytes, b64url_decode(sig_obj["sig"]))
return True
except BadSignatureError:
return False
یہ فنکشن ایک رسید لیتا ہے اور True واپس کرتا ہے اگر دستخط درست ہو، ورنہ False۔ نہ کوئی نیٹ ورک کال، نہ کوئی سروس انحصار، نہ کسی تیسرے فریق پر اعتماد۔
چھیڑچھاڑ کے پتہ چلانے کے لیے نوٹ بک یہ دیکھاتی ہے:
tool_args_hash فیلڈ کے ایک بائٹ میں ترمیم کرنا۔یہ عملی مظاہرہ ہے کہ رسیدیں چھیڑچھاڑ کا پتہ دیتی ہیں: کوئی بھی معمولی ترمیم دستخط کو ناکام کر دیتی ہے۔
ایک دستخط شدہ رسید ایک عمل کی حفاظت کرتی ہے۔ رسیدوں کی چین ایک سلسلے کی حفاظت کرتی ہے۔
flowchart LR
R0[رسید 0<br/>ابتدائیہ] --> R1[رسید 1]
R1 --> R2[رسید 2]
R2 --> R3[رسید 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
ہر رسید اپنی سے پہلے والی رسید کے ہیش کو ریکارڈ کرتی ہے۔ رسید 2 کو چپکے سے ہٹانے کے لئے حملہ آور کو چاہیئے کہ یا:
previous_receipt_hash فیلڈ میں ترمیم کرے (رسید 3 کا دستخط خراب ہو جائے)، یااگر پرائیویٹ کی ہارڈویئر کلید والیٹ میں ہو اور آپ ہر رسید کے ساتھ عوامی کلید شائع کریں، تو کوئی بھی حملہ بغیر پتا چلائے ممکن نہیں۔
نوٹ بک میں:
previous_receipt_hash سابقہ رسید کے اصل ہیش سے ملتا ہے۔یہ ہے کہ آپ ایسا آڈٹ ٹریل بناتے ہیں جسے بیرونی آڈیٹر آپ پر اعتماد کیے بغیر ویریفائی کر سکتا ہے۔
یہ سبق کا سب سے اہم حصہ ہے۔ رسیدیں طاقتور ہیں لیکن ان کی طاقت محدود ہے۔
رسیدیں تین چیزیں ثابت کرتی ہیں:
رسیدیں یہ ثابت نہیں کرتیں:
policy_id میں حوالہ دی گئی پالیسی کا اصل میں جائزہ لیا گیا، یا اگر چیک کی گئی تو یہ کارروائی قابلِ اجازت تھی۔ رسید صرف دعوی ثبت کرتی ہے، نفاذ نہیں۔یہ حد دو وجوہات کی بنا پر اہم ہے:
ایک عام غلط فہمی یہ ہے کہ “ہمارے پاس رسیدیں ہیں” کا مطلب “ہم حکومت کرتے ہیں” ہے۔ ایسا نہیں ہے۔ رسید ایک بنیاد ہے۔ حکمرانی وہ نظام ہے جو آپ اس کے اوپر بناتے ہیں۔
اوپر کی اشیاء میں سے نمبر 3 اپنی ایک علیحدہ سیکشن کے لائق ہے: ایک کارروائی کی رسید کہتی ہے “اس کلید نے یہ مواد دستخط کیا،” کبھی “یہ انسان نے اجازت دی” نہیں۔ اعلیٰ خطرے کی کارروائیوں (رقم کی واپسی، حذف کرنا، وائر ٹرانسفرز) کے لیے حکومتی فریم ورک ایسے بیان کی تقاضا بڑھ رہے ہیں، اور یہ وہی ابتدائیات ہیں جو آپ نے اس سبق میں بنائی ہیں۔
اگلی کتابچہ code_samples/human-authorization-receipts.ipynb ایک دوسرا رسید قسم شامل کرتا ہے، human.approval.v1، جو سبق کی رسیدوں کی ہی شکل میں ہوتا ہے (Ed25519 سے دستخط شدہ ٹائپ کیا گیا پے لوڈ، اس کے کینونیکل JCS بائٹس پر، دستخطی آبجیکٹ دستخط شدہ بائٹس کے باہر ہوتا ہے)۔ نامزد منظور کنندہ مکمل کینونیکل عمل اور اس کی ڈائجسٹ پر دستخط کرتا ہے قبل از عمل؛ ایجنٹ کی کارروائی کی رسید میں وہی عمل کی ڈائجسٹ شامل ہوتی ہے اور parent_approval_ref، منظور کی رسید کے receipt_hash جو آپ نے اوپر چین میں previous_receipt_hash کے طور پر استعمال کیا۔ ایک verify_chain الگ الگ کلید رجسٹریوں کے تحت دونوں اشیاء کو چیک کرتا ہے (منظور کنندگان کی چابیاں بمقابلہ ایجنٹ کی چابیاں)، لہٰذا کوڈ راستہ مشترکہ ہے مگر اتھارٹیز کبھی نہیں۔
یہ خصوصیت مہیا کی گئی ہے، محتاط انداز میں کہی گئی: انسان نے اسی خاص عمل کی منظوری دی، اور ایجنٹ نے بالکل وہی منظور شدہ عمل انجام دیا۔ نوٹ بک کی انکار کی خصوصیات ہی اسے محض دعویٰ کے بجائے حقیقت بناتی ہیں:
ہر ناکامی مختلف وجہ سے انکار کرتی ہے، تاکہ آڈیٹر انکار پڑھ کر بتا سکے کہ آیا اتھارٹی پرانی ہوئی یا انجام دی گئی کارروائی بدلی۔ نوٹ بک کی ہدایت: دستخط شدہ منظوری خود میں اتھارٹی نہیں ہے۔ اتھارٹی اس وقت موجود ہوتی ہے جب دونوں رسیدیں ابھی بھی ایک ہی کینونیکل عمل سے پابند ہوں۔ انسانی منظوری کی رسید ایک تعلیمی مجموعہ ہے جو اس سبق نے بیان کیا ہے، نہ کہ draft-farley-acta-signed-receipts کی جانب سے مقرر شدہ رسید کی قسم۔
اس سبق کا Python کوڈ جان بوجھ کر مختصر رکھا گیا ہے تاکہ آپ ہر لائن پڑھ سکیں اور جان سکیں کہ کیا ہو رہا ہے۔ پیداوار میں آپ کے پاس دو اختیارات ہیں:
کرپٹو گرافک پرائمیٹوز پر براہ راست تعمیر کریں۔ اوپر دکھائی گئی 50 لائنز کئی استعمال کے لیے کافی ہیں۔ PyNaCl (Ed25519) اور jcs پیکیج (کینونیکل JSON) اچھی طرح سے برقرار اور آڈٹ شدہ لائبریریاں ہیں۔
پیداواری رسید لائبریری استعمال کریں۔ متعدد اوپن سورس پراجیکٹس وہی نمونہ اضافی خصوصیات کے ساتھ نافذ کرتے ہیں (کی کلید کی گردش، بیچ کی تصدیق، JWK سیٹ کی تقسیم، پالیسی انجن کے ساتھ انضمام):
draft-farley-acta-signed-receipts, نظرثانی 02) میں JCS اور دستخط کے دائرہ کار کے روایات استعمال کرتا ہے۔ اس سبق کی سادہ تعلیمی رسید ڈرافٹ کے {payload, signature} لفافے سے مختلف ہے اور اسے مطابقتی نفاذ کے طور پر پیش نہیں کیا گیا۔ ڈرافٹ ایک مشترکہ کنفارمنس سویٹ (agent-governance-testvectors) شائع کرتا ہے جو اس کے وائر فارمیٹ ہدف بناتی ہے۔protect-mcp (npm) اور @veritasacta/verify (npm) پیکیجز Node پر مبنی رسید کی دستخط اور آف لائن تصدیق فراہم کرتے ہیں، جس کا مقصد کسی بھی MCP سرور کو چھیڑچھاڑ سے محفوظ آڈٹ ٹریل کے ساتھ لپیٹنا ہے، جس میں ایک held-for-co-sign فلو شامل ہے جہاں روک دی گئی کارروائی ایک منظوری رسید جاری کرتی ہے جو عمل کی ڈائجسٹ سے بندھی ہو (ڈیسک ٹاپ فلو میں WebAuthn کی حمایت کے ساتھ)، وہی منظوری-رسید نمونہ جو انسانی اجازت والی نوٹ بک میں ہے۔pip install nobulex) وہی Ed25519 + JCS دستخطی نمونہ Python میں LangChain اور CrewAI انضمام کے ساتھ فراہم کرتا ہے، شائع شدہ کراس ویلیڈیشن ٹیسٹ ویکٹرز اور OWASP PR #2210 کے ذریعے تعاون یافتہ کمپلائنس میپنگ سمیت۔اپنا خود کا حل بنانے اور لائبریری استعمال کرنے کا فیصلہ JWT لائبریری لکھنے اور آزمودہ لائبریری استعمال کرنے کے فیصلے سے مماثل ہے: دونوں معقول ہیں؛ لائبریری وقت بچاتی ہے اور آڈٹ کی سطح کم کرتی ہے؛ خود سے آغاز کا مطلب ہر پرائمیٹیو کو سمجھنا ہے۔ یہ سبق آپ کو خود سے سکھاتا ہے تاکہ آپ کے پاس دونوں اختیارات کا بنیاد ہو۔
عملی مشق سے پہلے اپنی سمجھ کو پرکھیں۔
1. رسید ایجنٹ کی پرائیویٹ Ed25519 کلید سے دستخط شدہ ہے۔ آڈیٹر کے پاس صرف عوامی کلید ہے۔ کیا آڈیٹر رسید کو آف لائن ویریفائی کر سکتا ہے؟
2. ایک حملہ آور نے رسید کے policy_id فیلڈ کو تبدیل کیا تاکہ الزام لگایا جا سکے کہ اسے زیادہ نرم پالیسی کے تحت چلایا گیا تھا۔ دستخط اصل پے لوڈ پر تھے۔ تصدیق کے دوران کیا ہوتا ہے؟
3۔ رسید میں tool_args_hash اور result_hash خام دلائل اور نتائج کی جگہ کیوں شامل کیے گئے ہیں؟
4۔ previous_receipt_hash فیلڈ ہر رسید کو اس کے پیشرو سے جوڑتا ہے۔ اگر حملہ آور زنجیر کے وسط سے ایک رسید خاموشی سے حذف کر دے، تو کیا غیر معتبر ہو جائے گا؟
5۔ ایک رسید صاف ستھری طریقے سے تصدیق ہو جاتی ہے۔ کیا یہ اس بات کا ثبوت ہے کہ ایجنٹ کا عمل درست، معقول، یا پالیسی کے مطابق تھا؟
code_samples/18-signed-receipts.ipynb کھولیں اور تمام چار حصے مکمل کریں:
1۔ حصہ 1: اپنی پہلی رسید پر دستخط کریں اور اس کی تصدیق کریں۔ 2۔ حصہ 2: رسید میں چھیڑ چھاڑ کریں اور تصدیق کی ناکامی دیکھیں۔ 3۔ حصہ 3: تین رسیدوں کی زنجیر بنائیں اور زنجیر کی سالمیت کی تصدیق کریں۔ 4۔ حصہ 4: مائیکروسافٹ ایجنٹ فریم ورک کے ساتھ بنائے گئے ایجنٹ پر اس نمونے کو لاگو کریں: ایک ٹول کال کو رسید دستخط کرنے میں لپیٹیں، پھر رسید کی آزادانہ تصدیق کریں۔
اضافی چیلنج 1: رسید کے اسکیمے میں اپنی پسند کا ایک اضافی فیلڈ شامل کریں (مثلاً، ٹریسنگ کے لیے درخواست کی شناخت)، کینونیکل دستخط کے منطقی عمل کو اس میں شامل کریں، اور تصدیق کریں کہ رسید اب بھی درست طور پر گزر جاتی ہے۔ پھر دستخط کے بعد فیلڈ میں ترمیم کریں اور تصدیق کی ناکامی یقینی بنائیں۔ یہ آپ کو سمجھنے پر مجبور کرے گا کہ کینونیکل انکوڈنگ کے ہر بائٹ کا دستخط پر کیا اثر ہوتا ہے۔
اضافی چیلنج 2: اپنی دو رسیدوں کے کینونیکل بائٹس کو ایک مقررہ ترتیب میں concatinate کر کے SHA-256 ہیش بنائیں اور نتیجے کو تیسرے رسید کے ایک نئے فیلڈ میں دستخط سے پہلے شامل کریں۔ تصدیق کریں کہ تمام تین رسیدیں اب بھی درست طریقے سے گزر جاتی ہیں۔ آپ نے اب صرف ایک قدم کا شمولیتی ثبوت بنایا ہے: جو بھی تیسرے رسید کا حامل ہو، ثابت کر سکتا ہے کہ پہلے دو رسیدیں دستخط کے وقت موجود تھیں بغیر ان کے مواد ظاہر کیے۔ یہی نمونہ وسیع پیمانے پر استعمال ہونے والے انتخابی افشاء رسیدوں میں ہوتا ہے (Merkle commitments, RFC 6962)۔
کرپٹوگرافک رسیدیں AI ایجنٹس کو ایک آڈٹ ٹریل دیتی ہیں جو:
یہ ان پٹ کی تصدیق، پالیسی نفاذ، یا شناخت کے انفراسٹرکچر کا متبادل نہیں ہیں۔ یہ ان تہوں کی بنیاد ہیں۔ جب آپ ایجنٹس کو منظم شدہ کاموں، کثیر تنظیمی ورک فلو، یا ایسے ماحول میں تعینات کر رہے ہوں جہاں مستقبل کا آڈیٹر آپ پر اعتماد کرنے کا مفروضہ نہیں رکھتا، تو رسیدیں ہی آڈٹ ٹریل کو ایماندار بناتی ہیں۔
سب سے اہم بات: رسیدیں یہ ثابت کرتی ہیں کہ کس نے کیا کہا اور کب کہا۔ یہ ثابت نہیں کرتی کہ جو کہا گیا وہ سچ یا درست تھا۔ اس فرق کو مضبوطی سے پکڑ کر رکھیں۔ یہ ایماندار ماخذ نظام اور گمراہ کن نظام کے درمیان فرق ہے۔
جب آپ اس سبق کو مکمل کر کے حقیقی ماحول میں رسید دستخط والے ایجنٹس تعینات کرنے کے لیے تیار ہوں:
https://your-org.example.com/.well-known/agent-keys.json۔Microsoft Foundry Discord میں شامل ہوں تاکہ دوسرے سیکھنے والوں سے مل سکیں، آفیس آورز میں شرکت کریں، اور اپنے AI ایجنٹس کے سوالات کے جواب حاصل کریں۔
یہ سبق واحد رسید دستخط اور ہیش زنجیر شدہ تسلسل کو کور کرتا ہے۔ یہی بنیادی اجزاء کئی زیادہ جدید نمونوں میں مل کر کام کرتے ہیں جو آپ کی نگرانی کی پوزیشن کے بہتر ہونے کے ساتھ سامنے آ سکتے ہیں:
authorization_*) اور عمل کے بعد (result_*) حصوں میں تقسیم کر کے الگ الگ دستخط کیے جاتے ہیں، یہ مفید ہوتا ہے جب اجازت کا فیصلہ اور مشاہدہ شدہ نتیجہ مختلف اہلکاروں یا وقتوں میں پیدا ہو۔ یہ سبق میں سکھائے جانے والے رسید فارمٹ پر اضافہ کرتا ہے۔result_hash میں رکھتے ہیں۔ حقیقی دنیا کے پیلوڈز اکثر ایک ٹول کے نتیجے سے زیادہ جامع ہوتے ہیں: پہلے کے فیصلے کی وضاحت (ماڈل پیش گوئی، زیرِ غور اختیارات، شواہد اور اس کی تکمیل، خطرے کی پوزیشن، جوابدہی کی زنجیر، دروازے کے نتیجے) سب پیلوڈ میں شامل ہو سکتے ہیں اور ایک کا واحد رسید کے ذریعے مہریں لگا دی جاتی ہیں۔ اس طرح رسید کا نقشہ مختصر رہتا ہے جبکہ ڈومین کے لحاظ سے پیلوڈ اسکیمے ترقی کرتے رہتے ہیں۔signature.alg فیلڈ میں ML-DSA-65 (NIST کا بعد از کوانٹم دستخط معیار) شامل کیا جا سکتا ہے جب آپ کو منتقلی کی ضرورت ہو۔ منتقلی کے دوران رسیدیں دوہری دستخط والی ہو سکتی ہیں۔ڈس کلیمر: یہ دستاویز AI ترجمہ سروس Co-op Translator کے ذریعے ترجمہ کی گئی ہے۔ جبکہ ہم درستگی کے لیے کوشاں ہیں، براہ کرم اس بات سے آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا عدم درستیاں ہو سکتی ہیں۔ اصل دستاویز اپنے مادری زبان میں مستند ماخذ سمجھی جائے گی۔ حساس معلومات کے لیے پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کی ذمہ داری ہم قبول نہیں کرتے۔