کوئی "کال-ہوم" تصدیق نہیں: مستقبل کے ڈیجیٹل بین الاقوامی ڈرائیونگ اجازت نامے کو ہر استعمال پر جاری کنندہ سے رابطہ کیوں نہیں کرنا چاہیے

منسوخی کسی بھی مستقبل کے ڈیجیٹل بین الاقوامی ڈرائیونگ اجازت نامے (IDP) کا سب سے مشکل مسئلہ ہے۔ اسے حل کرنے کا آسان ترین طریقہ سب سے خطرناک بھی ہے: جاری کنندہ کو ہر پیشکش میں شریک کیا جائے۔ ایک جدید سرحد پار ڈرائیونگ اسناد کو بطور ڈیفالٹ اس شارٹ کٹ سے انکار کرنا چاہیے۔

تقریباً ہر ڈیجیٹل شناخت کی تجویز میں ایک ہی یقین دہانی والا جملہ ہوتا ہے:

“اسناد کی فوری تصدیق کی جا سکتی ہے۔”

کبھی کبھی یہ جملہ حقیقی پیش رفت کی وضاحت کرتا ہے۔ کبھی کبھی یہ ایک دوستانہ صارف انٹرفیس کے ساتھ نگرانی کی وضاحت کرتا ہے۔

آج کے شائع شدہ معیارات پہلے ہی واضح کر چکے ہیں کہ ایک تصدیق کنندہ کو ہر بار اسناد دکھائے جانے پر جاری کنندہ سے رابطہ کرنے کی ضرورت نہیں ہے:

• NIST کا موجودہ mDL فن تعمیر یہ بتاتا ہے کہ ایک تصدیق کنندہ جاری کنندہ کے دستخط اور عوامی کلیدوں پر بھروسہ کر کے صداقت اور سالمیت کی توثیق کر سکتا ہے — جاری کنندہ سے کسی براہ راست رابطے کے بغیر۔
• AAMVA تصدیق کرتا ہے کہ ISO/IEC 18013-5 ڈیوائس ریٹریول کے لیے تعاون کا تقاضا کرتا ہے اور صرف اختیاری طور پر سرور ریٹریول کی اجازت دیتا ہے۔
• AAMVA نے یہ بھی خبردار کیا ہے کہ سرور ریٹریول کے تحت، جاری کنندہ اتھارٹی ہر استعمال پر حقیقی وقت میں شامل ہوتی ہے — یعنی وہ تکنیکی طور پر یہ ریکارڈ کر سکتی ہے کہ اسناد کب استعمال ہوئی، کیا ڈیٹا شیئر کیا گیا، اور آئی پی تجزیے سے مقام تک اندازہ لگا سکتی ہے۔

یہ کوئی معمولی حاشیہ نہیں ہے۔ یہ سرحد پار ڈرائیونگ اسناد کی اگلی نسل کے لیے مرکزی ڈیزائن سوال ہے۔

خطرناک شارٹ کٹ: چار سوالوں کو ایک نیٹ ورک کال میں سمیٹنا

ناقص فن تعمیر چار بالکل مختلف سوالوں کو جاری کنندہ کے پاس ایک واحد لائیو کال میں جمع کر دیتا ہے:

1. کیا یہ اسناد اصلی ہے؟
2. کیا اسے پیش کرنے والا شخص اصل حامل ہے؟
3. کیا اسناد خود ابھی بھی درست ہے؟
4. کیا بنیادی قومی ڈرائیونگ حق ابھی بھی نافذ ہے؟

ایک ناقص ڈیزائن کردہ نظام حقیقی وقت میں گھر کو فون کر کے چاروں کا جواب دیتا ہے۔ ایک اچھا ڈیزائن کردہ نظام انہیں الگ کرتا ہے — کیونکہ یہ ایک جیسا مسئلہ نہیں ہے اور انہیں ایک ہی طریقہ کار نہیں اپنانا چاہیے۔

صداقت کی توثیق مقامی طور پر ہونی چاہیے، نیٹ ورک پر نہیں

ایک اسناد کرپٹوگرافک طور پر اصلی ہو سکتی ہے بغیر جاری کنندہ کے لین دین کا مشاہدہ کیے۔

• NIST کا mDL ٹرسٹ ماڈل کہتا ہے کہ صداقت اور سالمیت کی توثیق جاری کنندہ کے دستخط اور عوامی کلیدوں سے کی جاتی ہے — کوئی لائیو جاری کنندہ رابطہ درکار نہیں۔
• AAMVA کی ڈیجیٹل ٹرسٹ سروس بالکل اسی لیے موجود ہے تاکہ تصدیق کنندگان کو فی لین دین کال بیکس کے بغیر درست جاری کنندہ کی عوامی کلیدوں تک رسائی دی جا سکے۔

ڈیزائن اصول 1: ایسے مسئلے کو حل کرنے کے لیے لائیو کنیکٹیویٹی استعمال نہ کریں جسے دستخط پہلے ہی حل کر دیتے ہیں۔

اگر ایک تصدیق کنندہ کے پاس قابل اعتماد جاری کنندہ کلیدیں ہیں اور اسے معیارات کے مطابق پیشکش ملتی ہے، تو صداقت ایک مقامی کرپٹوگرافک جانچ ہے، نیٹ ورک کا انحصار نہیں۔

حامل کی پہچان مقامی طور پر ثابت ہونی چاہیے، عالمی سطح پر رپورٹ نہیں

دوسرا سوال — کیا یہ اصل حامل ہے؟ — کا جواب بھی بغیر نیٹ ورک کے ممکن ہے۔

موجودہ EUDI فن تعمیر PIDs اور ISO/IEC 18013-5 تصدیقات کے لیے ڈیوائس بائنڈنگ کو لازمی قرار دیتا ہے۔ تصدیق کنندہ والٹ سے کہتا ہے کہ وہ ایک تازہ چیلنج پر اس نجی کلید کا استعمال کرتے ہوئے دستخط کرے جو اسناد میں سرایت کردہ عوامی کلید سے مطابقت رکھتی ہے:

• ISO/IEC 18013-5 میں اسے mdoc authentication کہتے ہیں۔
• SD-JWT VC میں اسے key binding کہتے ہیں۔

دونوں صورتوں میں، قبضہ مقامی اور کرپٹوگرافک طور پر ثابت ہوتا ہے۔ کوئی ذاتی ڈیٹا جاری کنندہ تک پہنچنے کی ضرورت نہیں۔

ڈیزائن اصول 2: قبضہ مقامی طور پر ثابت کریں۔ شناخت عالمی سطح پر ثابت نہ کریں۔

مستقبل کے IDP کو جاری کنندہ کی طرف سے کسی بھی طریقہ کار پر غور کرنے سے پہلے ڈیوائس بائنڈنگ، مقامی حامل تصدیق، اور تصدیق کنندہ چیلنج-ریسپانس کو مکمل طور پر استعمال کرنا چاہیے۔

اسناد کی حیثیت اور ڈرائیونگ حق کی حیثیت دو مختلف چیزیں ہیں

بہت سے ڈیجیٹل شناخت کے ڈیزائن اس فرق کو دھندلا دیتے ہیں، اور یہیں وہ غلط ہو جاتے ہیں۔

W3C کی Bitstring Status List تفصیل اس نکتے کو واضح کرتی ہے: ایک قابل تصدیق اسناد سے منسلک حیثیت کی معلومات اسی قابل تصدیق اسناد پر لاگو ہوتی ہے — ضروری نہیں کہ بنیادی حقیقی دنیا کے استحقاق پر۔ ایک ڈیجیٹل اسناد اس لیے منسوخ ہو سکتی ہے کیونکہ اس کا دستخط کرنے کا طریقہ کار سمجھوتہ کر لیا گیا تھا، جبکہ بنیادی ڈرائیونگ حق بالکل درست رہتا ہے۔

اس لیے مستقبل کے IDP کو دو الگ حیثیت کی تہیں درکار ہیں:

• اسناد حیثیت کی تہہ — ڈیجیٹل اسناد یا پیشکش چینل کے لیے۔
• ڈرائیونگ حق کی تہہ — گاڑی چلانے کے بنیادی قومی استحقاق کے لیے۔

کبھی کبھی یہ ایک ساتھ بدلتے ہیں۔ اکثر وہ نہیں بدلتے۔ جو نظام انہیں آپس میں ملا دیتا ہے وہ ضرورت سے زیادہ ردعمل ظاہر کرے گا، ضرورت سے زیادہ ڈیٹا ظاہر کرے گا، یا دونوں کام کرے گا۔

والٹ کے سمجھوتے کو حیثیت کے ذریعے آگے بڑھنا چاہیے — تصدیق کنندہ کال بیکس کو متحرک نہیں کرنا چاہیے

مستقبل کے IDP کو اس بارے میں بھی ایک واضح جواب درکار ہے کہ جب والٹ سمجھوتہ ہو جائے تو کیا ہوتا ہے۔

EUDI فن تعمیر ایک جواب فراہم کرتا ہے:

• والٹ فراہم کنندہ منسوخی کی معلومات پر مشتمل Wallet Unit Attestations جاری کرتا ہے۔
• والٹ کی سالمیت وقت کے ساتھ دوبارہ تصدیق کی جاتی ہے؛ اگر والٹ مزید محفوظ نہیں ہے، تو اس کی تصدیق منسوخ کر دی جاتی ہے۔
• PID فراہم کنندگان کو باقاعدگی سے جانچنا ہوگا کہ آیا والٹ منسوخ ہو گیا ہے۔ اگر ہو گیا ہے، تو وہ PID منسوخ کر دیتے ہیں۔
• PID کی حیثیت کی تصدیق کر کے، انحصار کرنے والی پارٹی مضمنی طور پر والٹ کی حیثیت کی تصدیق کرتی ہے۔

یہ وہ تہ بندی ہے جو مستقبل کے IDP کو اپنانی چاہیے۔ یہ نہ کریں کہ ہر تصدیق کنندہ سے آزادانہ طور پر والٹ فراہم کنندہ کو جانچنے کا مطالبہ کیا جائے۔ والٹ کے سمجھوتے کو موجودہ اسناد حیثیت پائپ لائن کے ذریعے پھیلنے دیں، اور تصدیق کنندگان کو اس واحد رازداری کے حامل چینل سے مشورہ کرنے دیں۔

منسوخی کے تین قابل عمل طریقے (کوئی کال بیکس درکار نہیں)

EUDI فراہم کنندگان کو منسوخی کے تین طریقوں میں سے ایک استعمال کرنے کا تقاضا کرتا ہے:

• قلیل مدتی تصدیقات — 24 گھنٹے یا اس سے کم کے لیے درست، اس لیے منسوخی غیر ضروری ہو جاتی ہے۔
• Attestation Status List — ایک شائع شدہ فہرست جسے تصدیق کنندگان مشاورت کر سکتے ہیں۔
• Attestation Revocation List — منسوخ شدہ اسناد کی ایک واضح فہرست۔

24 گھنٹے سے زیادہ درست تصدیقات کے لیے، EUDI کا تقاضا ہے کہ منسوخی کی معلومات شامل کی جائیں جن میں شامل ہیں:

• ایک URL جہاں سے انحصار کرنے والی پارٹیاں حیثیت کی فہرست حاصل کر سکتی ہیں۔
• ایک شناخت کنندہ جو اس فہرست میں اسناد کی جگہ بتاتا ہے۔

اگر قابل اعتماد منسوخی کی معلومات دستیاب نہ ہوں — مثال کے طور پر، جب انحصار کرنے والی پارٹی آف لائن ہو — EUDI انحصار کرنے والی پارٹی کو اسناد قبول یا مسترد کرنے سے پہلے ایک خطرے کا تجزیہ کرنے کی ہدایت دیتا ہے۔

نتیجہ: منسوخی کوئی واحد طریقہ کار نہیں ہے، اور یقیناً لازمی جاری کنندہ کال بیکس کا جواز نہیں۔

بطور ڈیفالٹ قلیل مدتی، طویل مدتی صرف جہاں ضروری ہو

پورے اسٹیک میں سب سے مؤثر رازداری کے اقدامات میں سے ایک سب سے سادہ بھی ہے: جو پیش کیا جائے اسے قلیل مدتی رکھیں۔

• EUDI کہتا ہے کہ 24 گھنٹے یا اس سے کم کے لیے درست تصدیقات کو منسوخی کے بنیادی ڈھانچے کی ضرورت نہیں — وہ منسوخی سے پہلے ختم ہو جاتی ہیں۔
• W3C کہتا ہے کہ قابل تصدیق پیشکشیں عام طور پر قلیل مدتی ہوتی ہیں اور طویل مدتی ذخیرہ کے لیے ڈیزائن نہیں کی گئی ہیں۔
• NIST نے روزمرہ استعمال کے لیے قابل استعمال شناخت کنندگان کو بار بار منتقل کرنے کے خلاف واضح طور پر خبردار کیا ہے۔ روزمرہ کی تصدیق کو اسی مقصد کے لیے بنائی گئی ٹیکنالوجیز پر انحصار کرنا چاہیے، جیسے passkeys، نہ کہ شناخت سے بھرپور اسناد کی بار بار پیشکش۔
• NIST نے سرور کی طرف بایومیٹرک ملاپ کے بجائے مقامی ڈیوائس تصدیق کا انتخاب کیا خاص طور پر اس لیے کہ مقامی تصدیق رازداری کو برقرار رکھتی ہے اور آپریشنل طور پر زیادہ موثر ہے۔

ڈیزائن اصول 3: بنیادی اسناد کی درمیانی درستگی کی مدت ہو سکتی ہے، لیکن پیشکش خود قلیل مدتی، تصدیق کنندہ مخصوص، اور غیر قابل استعمال ہونی چاہیے۔

حیثیت کی فہرستیں درست ڈیفالٹ طریقہ کار ہیں

جب آپ سب کچھ قلیل مدتی نہیں بنا سکتے، تو آپ کو حیثیت کے بنیادی ڈھانچے کی ضرورت ہے — اور حیثیت کی فہرست درست ڈیفالٹ ہے۔

W3C کی Bitstring Status List v1.0 ایک رازداری کو محفوظ رکھنے والے، جگہ بچانے والے، اور اعلیٰ کارکردگی والے طریقہ کار کی وضاحت کرتی ہے جو معطلی یا منسوخی جیسی حیثیت کا ڈیٹا شائع کرنے کے لیے ہے۔ اہم خصوصیات میں شامل ہیں:

• ہر جاری کنندہ اپنی جاری کردہ اسناد کے لیے ایک فہرست کا انتظام کرتا ہے۔
• فارمیٹ اچھی طرح سکڑتا ہے، کیونکہ زیادہ تر اسناد منسوخ نہیں رہتیں۔
• ڈیفالٹ فہرست کا سائز 131,072 اندراجات ہے، جو W3C کے مطابق عام صورت میں کافی گروہی رازداری فراہم کرتا ہے۔
• جہاں مضبوط گروہی رازداری کی ضرورت ہو وہاں بڑی فہرستیں استعمال کی جا سکتی ہیں۔

اس سے سوال یہ بدل جاتا ہے:

“کیا میں ابھی اس صارف کے بارے میں جاری کنندہ سے پوچھ سکتا ہوں؟”

سے:

“کیا میرے پاس پہلے سے کافی حالیہ رازداری کو محفوظ رکھنے والی حیثیت کی فہرست ہے کہ میں مقامی طور پر فیصلہ کر سکوں؟”

یہ ایک بہت بہتر سوال ہے — تکنیکی اور سیاسی دونوں لحاظ سے۔

“کوئی کال-ہوم نہیں” ایک ڈاؤنلوڈ پیٹرن ہے، نہ کہ نعرہ

EUDI کی رازداری رہنمائی میں سب سے اہم اصول طریقہ کاری ہے، فلسفیانہ نہیں۔

انحصار کرنے والی پارٹیوں کو ہر بار اسناد پیش کیے جانے پر حیثیت کی فہرست مانگنی نہیں چاہیے۔ اس کے بجائے، انہیں:

• فہرست کا ہر نیا ورژن ایک بار ڈاؤنلوڈ کرنا چاہیے۔
• ایسا کسی وقت اور مقام پر کریں جو کسی بھی صارف کی پیشکش سے غیر متعلق ہو۔
• فہرست کو انحصار کرنے والی پارٹی کی تنظیم کے اندر اندرونی طور پر تقسیم کریں۔
• انحصار کرنے والی پارٹی کی تصدیق کیے بغیر فہرست حاصل کریں۔

یہ کوئی کال-ہوم تصدیق کا آپریشنل بنیادی حصہ ہے: حیثیت کو صارف کی پیشکشوں سے الگ تازہ کریں — کبھی فی شخص نہیں، کبھی فی لین دین نہیں۔

یہ واحد ڈیزائن انتخاب جاری کنندہ یا حیثیت فراہم کنندہ کو یہ جاننے سے روکتا ہے کہ کس تصدیق کنندہ نے کس اسناد کو کس لمحے چیک کیا۔

گروہی رازداری: وہ تقاضا جسے زیادہ تر ڈیزائن بھول جاتے ہیں

بہت سے نظام پیشکش کے اندر انتخابی انکشاف کا اعلان کرتے ہیں، پھر خاموشی سے حیثیت کی تلاش کی رازداری کو نظر انداز کر دیتے ہیں۔ یہ ایک اہم خلا ہے۔

EUDI کی رازداری کی ضروریات بتاتی ہیں کہ:

• حیثیت کی فہرستوں میں اشاریہ جات بے ترتیب تفویض کیے جائیں، تاکہ اشاریہ خود کبھی ٹریکنگ سگنل نہ بنے۔
• ہر فہرست کو گروہی رازداری کو یقینی بنانے کے لیے کافی بڑی تعداد کی اسناد کا احاطہ کرنا چاہیے۔
• اگر کوئی فہرست بصورت دیگر بہت چھوٹی ہو، تو فراہم کنندگان کو اصل اسناد کی تعداد چھپانے کے لیے غیر استعمال شدہ اندراجات شامل کرنے چاہئیں۔

مستقبل کا IDP صرف انتخابی انکشاف کی بنیاد پر رازداری کا دعویٰ نہیں کر سکتا۔ اگر منسوخی کا طریقہ کار پیشکش کے واقعے کو ظاہر کرتا ہے، تو رازداری کا ڈیزائن نامکمل ہے۔

آف لائن آپریشن کوئی غیر معمولی معاملہ نہیں — یہ ایک بنیادی تقاضا ہے

کوئی بھی سفری نظام جو کامل کنیکٹیویٹی کا فرض کرتا ہے ناقص ڈیزائن کردہ ہے۔

• AAMVA تصدیق کرتا ہے کہ ڈیوائس ریٹریول حامل ڈیوائس اور ریڈر دونوں کے لیے بیرونی کنیکٹیویٹی کے بغیر کام کرتا ہے، اور یہ کہ ISO/IEC 18013-5 mDLs کو ڈیوائس ریٹریول کو سپورٹ کرنے کا تقاضا کرتا ہے۔
• EUDI تسلیم کرتا ہے کہ انحصار کرنے والی پارٹیاں آف لائن ہو سکتی ہیں اور ان کے پاس کیشڈ حیثیت کی فہرست نہ ہو، ایسی صورت میں وہ فیصلہ کرنے سے پہلے خطرے کا تجزیہ کرنے کی سفارش کرتا ہے۔

اس سمجھوتے کو جلد قبول کریں:

آپ کامل آف لائن آپریشن اور کامل حقیقی وقت کی تازگی ایک ساتھ نہیں پا سکتے۔

کوئی بھی فن تعمیر جو سمجھوتے کے بغیر دونوں کا وعدہ کرتا ہے یا تو غیر واضح ہے یا خاموشی سے نگرانی کو دوبارہ متعارف کرا رہا ہے۔ صحیح ردعمل تازگی کو پالیسی ان پٹ بنانا ہے، نہ کہ عالمگیر نیٹ ورک انحصار۔

لاگز وہاں ہیں جہاں رازداری خاموشی سے ناکام ہوتی ہے

ایک بہترین حیثیت فن تعمیر کو بھی لاپرواہ لاگنگ کمزور کر سکتی ہے۔

• EUDI انحصار کرنے والی پارٹی کے مثالوں سے تقاضا کرتا ہے کہ وہ منفرد عناصر اور ٹائم اسٹامپس کو اب ان کی ضرورت نہ رہنے کے فوراً بعد ضائع کریں، اور انہیں آگے بھیجنے سے منع کرتا ہے۔
• AAMVA اسٹیک ہولڈرز کو mDL حاملین یا mDL استعمال کو ٹریک کرنے سے روکتا ہے سوائے جہاں قانون کی ضرورت ہو، جاری کرنے والی اتھارٹیز کو جامد یا طویل المدت میٹا ڈیٹا کا اشتراک کم سے کم کرنے کی ضرورت ہے، اور سرگرمی لاگ تک رسائی صرف حامل کے لیے محدود کرتا ہے۔
• AAMVA نے یہ بھی تقاضا کیا ہے کہ آن-ڈیوائس حذف کرنے سے وہ لاگ معلومات اور میٹا ڈیٹا ہٹ جائے جو استعمال کی تاریخ ظاہر کر سکتا ہے — اور یہ حذف کرنا آف لائن ممکن ہو۔

یہ پروٹوکول برتاؤ ہے، نہ کہ انتظامی گھریلو کام۔ مستقبل کے IDP کو طویل المدت شناخت کنندگان، ٹائم اسٹامپس، اور لاگز کو ممکنہ ٹریکنگ ٹولز کے طور پر سمجھنا چاہیے جب تک کہ واضح طور پر دوسری صورت ثابت نہ ہو جائے۔

مستقبل کے IDP کے لیے ایک ٹھوس کوئی کال-ہوم نہیں فن تعمیر

اصولوں کو یکجا کرتے ہوئے، یہاں ہے کہ نظام کو اصل میں کیا کرنا چاہیے:

1. ڈیوائس سے منسلک بنیادی اسناد جاری کریں۔ اسناد کو والٹ کے محفوظ ماحول میں محفوظ کلیدوں سے باندھیں — EUDI کے تحت PIDs اور ISO/IEC 18013-5 تصدیقات کے لیے لازمی۔
2. صرف وہی مانگیں جو ضروری ہو، تازہ چیلنج کے ساتھ۔ ایک OpenID4VP لین دین میں، ایک DCQL سوال والٹ کو حامل کو یہ دکھانے دیتا ہے کہ کون سی صفات مانگی جا رہی ہیں، اور تصدیق کنندہ دوبارہ چلانے سے روکنے کے لیے ایک چیلنج جاری کرتا ہے۔
3. ایک قلیل مدتی پیشکش تیار کریں، قابل استعمال شناخت کنندہ نہیں۔ ہر پیشکش تصدیق کنندہ، درخواست، اور لمحے کے لیے مخصوص ہونی چاہیے۔
4. صداقت کو مقامی طور پر تصدیق کریں۔ جاری کنندہ کے دستخط اور عوامی کلیدوں کو آف لائن توثیق کریں؛ AAMVA کی ٹرسٹ سروس بالکل اسی کے لیے بنائی گئی ہے۔
5. کیشڈ، الگ سے تازہ شدہ فہرستوں سے حیثیت جانچیں۔ جہاں اسناد منسوخی کو چھوڑنے کے لیے بہت طویل المدت ہوں، وہاں مقامی طور پر کیشڈ حیثیت کی فہرستیں استعمال کریں جو صارف کی پیشکشوں سے غیر متعلق شیڈول پر تازہ ہوں۔
6. جب تازگی دستیاب نہ ہو تو خطرے کی پالیسی لاگو کریں۔ آف لائن فیصلوں کو واضح تصدیق کنندہ پالیسی بنائیں، بے ترتیب اندازہ نہیں۔
7. ٹریکنگ ڈیٹا کو سرگرمی سے حذف کریں۔ لین دین کے منفرد عناصر اور ٹائم اسٹامپس کو جب ضرورت نہ رہے تو ضائع کریں؛ وہ لاگز نہ رکھیں جو نقل و حرکت کی تاریخ کو دوبارہ تشکیل دے سکیں۔

ایک سنجیدہ کوئی کال-ہوم نہیں فن تعمیر اسی طرح نظر آتا ہے — تہ دار، رازداری کو محفوظ رکھنے والا، کرپٹوگرافک طور پر مقامی، اور آف لائن حقیقت کے بارے میں آپریشنل طور پر ایماندار۔

تین پیٹرن جو ڈیزائن کے ذریعے ممنوع ہونے چاہئیں

ایک پختہ مستقبل کا IDP ایکو سسٹم انہیں فن تعمیر کی ناکامیاں سمجھے، نہ کہ بہتری کے انتخاب:

• ہر پیشکش پر جاری کنندہ کی لازمی کال بیکس۔ AAMVA کی اپنی رازداری رہنمائی وضاحت کرتی ہے کہ یہ نقصاندہ کیوں ہے۔
• ڈرائیونگ اسناد کو معمول کے لاگ ان کے طور پر استعمال کرنا۔ NIST نے واضح طور پر روزانہ کی تصدیق کے لیے شناخت بردار اسناد کو بار بار پیش کرنے کے خلاف خبردار کیا ہے۔
• شناخت کنندگان، ٹائم اسٹامپس، اور لاگز کو برقرار رکھنا جو پیشکش کی تاریخ کو دوبارہ تشکیل دے سکتے ہیں۔ EUDI اور AAMVA دونوں اس کے برعکس تقاضا کرتے ہیں۔

ایک جملے میں بنیادی دلیل

فوری تصدیق جاری کنندہ کی طرف سے نگرانی کی اجازت نہیں بننی چاہیے۔

مستقبل کا IDP کرنے کے قابل ہونا چاہیے:

• صداقت مقامی طور پر ثابت کریں۔
• قبضہ مقامی طور پر ثابت کریں۔
• تازگی نجی طور پر جانچیں۔
• آف لائن حقیقت کو برداشت کریں۔
• جب کامل معلومات دستیاب نہ ہو تو فضل کے ساتھ کام کریں۔

ان میں سے کوئی بھی نظام کو کمزور نہیں کرتا۔ یہ اسے بڑے پیمانے پر تعینات کرنے کے قابل بناتا ہے۔

جس لمحے ایک ڈرائیونگ اسناد یہ ریکارڈ کرنے کا آلہ بن جائے کہ کس نے کیا، کہاں، اور کب دکھایا، تو یہ کاغذ کا محفوظ ورژن نہیں رہتا۔ یہ مشاہدے کا بنیادی ڈھانچہ بن جاتا ہے۔

یہی وہ چیز ہے جس کو مستقبل کے IDP کو بننے سے انکار کرنا چاہیے۔

اکثر پوچھے گئے سوالات

“کال-ہوم تصدیق” کیا ہے؟
یہ کوئی بھی ڈیزائن ہے جس میں ایک تصدیق کنندہ اسناد کی توثیق کرنے کے لیے جاری کنندہ سے حقیقی وقت میں رابطہ کرتا ہے۔ اگرچہ یہ صداقت اور منسوخی دونوں کو ایک ساتھ حل کرتا ہے، لیکن یہ جاری کنندہ کو ہر پیشکش کے واقعے کا مشاہدہ کرنے دیتا ہے۔

کیا ISO/IEC 18013-5 آن لائن جاری کنندہ رابطے کا تقاضا کرتا ہے؟
نہیں۔ AAMVA تصدیق کرتا ہے کہ ISO/IEC 18013-5 ڈیوائس ریٹریول کے لیے تعاون کا تقاضا کرتا ہے اور صرف اختیاری طور پر سرور ریٹریول کی اجازت دیتا ہے۔

جاری کنندہ سے رابطہ کیے بغیر منسوخی کیسے کام کر سکتی ہے؟
قلیل مدتی اسناد، attestation status lists، یا attestation revocation lists کے ذریعے — مثالی طور پر انحصار کرنے والی پارٹی صارف کی پیشکشوں سے الگ حیثیت کا ڈیٹا ڈاؤنلوڈ کرے۔

حیثیت کی فہرستوں کے لیے “گروہی رازداری” کیوں اہم ہے؟
اگر حیثیت کی فہرست بہت چھوٹی ہو یا اس کے اشاریہ جات قابل پیشگوئی ہوں، تو ایک حیثیت کی درخواست ظاہر کر سکتی ہے کہ کون سی مخصوص اسناد ابھی پیش کی گئی تھی۔ بے ترتیب اشاریہ جات اور بڑی فہرستیں اسے روکتی ہیں۔

کیا آف لائن تصدیق واقعی عملی ہے؟
ہاں — اور معیارات بنانے والے اداروں بشمول AAMVA اور EUDI نے اسے واضح طور پر ضروری قرار دیا ہے۔ سمجھوتہ یہ ہے کہ کامل حقیقی وقت کی تازگی کامل آف لائن آپریشن کے ساتھ مطابقت نہیں رکھتی، اس لیے تازگی کو پالیسی فیصلہ بنانا ہوگا، نہ کہ سخت انحصار۔