پولیس، کرایہ ڈیسک، آجر، بیمہ کار: وہ ایک جیسا ڈیٹا کیوں نہیں دیکھ سکتے

مستقبل کے بین الاقوامی ڈرائیونگ پرمٹ (IDP) کی سب سے بڑی ڈیزائن غلطی یہ ہوگی کہ ہر تصدیق کنندہ کو ایک جیسا سمجھا جائے۔ ایک پولیس افسر، کار کرایہ ڈیسک، ایک آجر، اور ایک بیمہ کار ایک ہی سوال نہیں پوچھتے — لہذا انہیں ایک ہی جواب نہیں ملنا چاہیے۔

ایک ڈرائیور۔ ڈرائیو کرنے کا ایک بنیادی حق۔ ایک والٹ۔ لیکن چار بالکل مختلف تصدیق کنندگان:

• سڑک کنارے ایک پولیس افسر
• گاڑی لینے کے وقت کار کرایہ ڈیسک
• فلیٹ اہلیت چیک کرنے والا آجر
• دعوے کا جائزہ لینے والا بیمہ کار

اگر مستقبل کا IDP چاروں کو ایک ہی ڈیٹا دکھائے، تو نظام پہلے ہی ناکام ہو چکا ہے۔ اس لیے نہیں کہ اسناد غیر محفوظ ہیں، بلکہ اس لیے کہ افشاء کا ماڈل بہت سادہ ہے۔

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

جسمانی کارڈ نے ہمیں غلط سوچنا کیوں سکھایا

ایک جسمانی لائسنس نے ہمیں سب کچھ دکھانے کے طریقے میں تربیت دی۔ آپ کارڈ دیتے ہیں۔ دوسرا شخص وہ دیکھتا ہے جو کارڈ پر ہے۔ یہی پوری بات چیت ہے۔

یہ طریقہ کاغذی دنیا میں قابل قبول ہے کیونکہ کوئی متبادل نہیں۔ ڈیجیٹل دنیا میں یہ ناقابل قبول ہو جاتا ہے۔

W3C VC ڈیٹا ماڈل 2.0 براہ راست کہتا ہے: ڈرائیور کے لائسنس میں شناختی نمبر، قد، وزن، سالگرہ اور گھر کا پتہ شامل ہو سکتا ہے — لیکن یہ پھر بھی کسی مخصوص لین دین کے لیے ضروری سے کہیں زیادہ ہو سکتا ہے۔ موجودہ معیارات کے اہم نکات:

• W3C بہترین عمل: منتخب افشاء کی حمایت کریں، اور صرف وہی طلب کریں جو سختی سے ضروری ہو
• یورپی یونین ڈیٹا تحفظ رہنمائی: پروسیسنگ مخصوص مقاصد تک محدود ہونی چاہیے، اور جو ڈیٹا پروسیس کیا جائے وہ ضروری اور متناسب ہونا چاہیے
• مستقبل کے IDP کا پہلا اصول: ایک جیسی اسناد کا مطلب جانچ کا ایک جیسا حق نہیں

درست ماڈل پالیسی پر مبنی افشاء ہے

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

NIST SP 800-205 رسائی کنٹرول فیصلوں کو موضوع، چیز، مطلوبہ آپریشن، اور ماحولی حالات سے منسلک صفات کی پالیسی کے خلاف تشخیص کے طور پر بیان کرتا ہے۔ یہ بالکل مستقبل کے IDP کے لیے درست ڈھانچہ ہے:

• موضوع: ڈرائیور
• چیز: مطلوبہ ڈیٹا فیلڈز
• عمل: تجریدی طور پر ‘لائسنس دیکھنا’ نہیں، بلکہ کچھ مخصوص جیسے ‘سڑک کنارے زمرہ B چلانے کا حق تصدیق کرنا’ یا ‘بکنگ کے لیے کرایہ اہلیت تصدیق کرنا’
• ماحول: سڑک کنارہ، کرایہ ڈیسک، ریموٹ پری چیک، فلیٹ آن بورڈنگ، اور نقصان کے بعد دعوے کا جائزہ مختلف ماحول ہیں اور مختلف فیصلوں کی طرف لے جانے چاہئیں

NIST یہ بھی نوٹ کرتا ہے کہ صفت نظاموں کو دانے داری، گورننس، اور صفات کی کمی، گروپ بندی اور کم سے کم کرنے کے میکانزم کی ضرورت ہے۔

لہذا مستقبل کا IDP یہ نہیں پوچھنا چاہیے: کیا یہ تصدیق کنندہ لائسنس پڑھ سکتا ہے؟ بلکہ اسے پوچھنا چاہیے: اس تصدیق کنندہ کو کون سے دعوے مل سکتے ہیں، کس مطلوبہ استعمال کے لیے، اس ماحول میں، کس برقراری قاعدے کے ساتھ؟

تصدیق کنندہ کو کچھ بھی مانگنے سے پہلے اپنی شناخت ظاہر کرنی چاہیے

مستقبل کا IDP والٹ کے ڈیٹا دکھانے سے شروع نہیں ہونا چاہیے۔ یہ تصدیق کنندہ کی اپنی شناخت ثابت کرنے سے شروع ہونا چاہیے۔

EUDI فن تعمیر اس بارے میں واضح ہے۔ انحصار کرنے والی فریقین کو:

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

صارف پھر دیکھ سکتا ہے کہ کون پوچھ رہا ہے، کیا مانگا جا رہا ہے، اور کیا درخواست رجسٹرڈ دائرے کے اندر ہے۔

ETSI کا موجودہ والٹ-انحصار-فریق سرٹیفکیٹ کام اسے مزید ٹھوس بناتا ہے۔ والٹ-انحصار-فریق رجسٹریشن سرٹیفکیٹ انحصار کرنے والی فریق کے مطلوبہ استعمال اور اس کی رجسٹرڈ مطلوبہ صفات کی وضاحت کر سکتا ہے۔ متعلقہ رسائی سرٹیفکیٹ اس بات کو یقینی بنانے کے لیے موجود ہے کہ درخواست ایک جائز، مجاز فریق سے آئے۔ ETSI میں انحصار کرنے والی فریق کا میٹا ڈیٹا بھی شامل ہے جیسے:

• تجارتی نام
• سپورٹ URI
• مطلوبہ استعمال
• استحقاقات
• رجسٹری URI
• نگران اتھارٹی کی معلومات

مستقبل کے IDP کا دوسرا اصول: تصدیق کنندہ کی شناخت نہیں، تو افشاء نہیں۔

رضامندی کی اسکرینیں کافی کیوں نہیں ہیں

یہاں ایک اور غلطی ہے: صارف کی منظوری کو قانونی جواز کے ساتھ یکساں سمجھنا۔

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

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

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

• خفیہ نگاری تصدیق کنندہ توثیق یہ تصدیق کرنے کے لیے کہ کون پوچھ رہا ہے
• پالیسی پابندیاں اس بات پر کہ وہ تصدیق کنندہ زمرہ کیا مانگ سکتا ہے

بغیر دونوں کے، ‘صارف کی پسند’ پالیسی کی ناکامی کو فرد پر منتقل کرنے کا طریقہ بن جاتا ہے۔

1. پولیس: گاڑی چلانے کے حق کی تصدیق کریں، پوری شخصیت کی نہیں

پولیس سڑک کنارہ منظرنامہ سب سے زیادہ مرکوز ہے۔

یورپی یونین mDL دستی اسے براہ راست بیان کرتا ہے: پولیس یا دیگر اہلکار ضرورت پڑنے پر لائسنس کی جانچ کرتے ہیں، بشمول لائسنس کی میعاد اور گاڑی کے استحقاقات۔ صارف کے سفر میں، افسر QR ٹرگرڈ فلو، بلوٹوتھ، Wi-Fi Aware، یا NFC کے ذریعے لائسنس کی تصدیق کرتا ہے۔ یہ ایک مرکوز تصدیقی کام ہے:

• کیا یہ شخص حامل ہے؟
• کیا اسناد درست ہیں؟
• کون سے گاڑی کے استحقاقات اور پابندیاں لاگو ہوتی ہیں؟

بطور ڈیفالٹ اجازت ہے:

• نام
• تصویر
• لائسنس کی حیثیت
• اجراء اور میعاد ختم ہونے کی تاریخیں
• زمرے
• ڈرائیونگ سے متعلق پابندیاں
• جاری کنندہ اور دائرہ اختیار
• تازگی/حیثیت نتیجہ

بطور ڈیفالٹ اجازت نہیں:

• گھر کا پتہ
• سڑک کنارہ استعمال کے لیے غیر ضروری اندرونی شناخت کار
• دیگر تصدیقات سے غیر متعلق صفات
• تاریخی پیشکش لاگز
• تجارتی میٹا ڈیٹا

AAMVA کی نفاذ رہنمائی تصویر کے نکتے کو تقویت دیتی ہے: اگر تصویر مانگی گئی ہو اور کوئی دوسرا عنصر جاری کیا گیا ہو، تو تصویر شیئر کی جانی چاہیے تاکہ تصدیق کنندہ ڈیٹا کو پیش کرنے والے سے جوڑ سکے۔ وہی رہنمائی یہ بھی کہتی ہے کہ اسٹیک ہولڈرز کو mDL حاملین یا mDL استعمال کو ٹریک نہیں کرنا چاہیے سوائے جہاں قانون کے تحت ضروری ہو۔

پولیس کا معاملہ ریاست کے سب کچھ حاصل کرنے کے بارے میں نہیں ہے۔ یہ ریاست کے سڑک کنارہ نافذ کرنے کے لیے ضروری ڈرائیونگ مخصوص ڈیٹا حاصل کرنے کے بارے میں ہے۔ یہ ایک اہم فرق ہے۔

2. کرایہ ڈیسک: اہلیت، شناخت ملاپ، اور کچھ غیر ضروری نہیں

کرایہ کا معاملہ زیادہ تفصیلی ہے کیونکہ واقعی دو لمحے ہیں: آمد سے پہلے ریموٹ پری چیک، اور چابیاں حوالے کرتے وقت پک اپ۔

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

کرایہ ڈیسک کو بنیادی طور پر کسی واقعے کی تحقیق کی ضرورت نہیں۔ اسے فیصلہ کرنا ہے: کیا میں اس بکنگ اور پالیسی کے تحت اس گاہک کو یہ گاڑی کرایے پر دے سکتا ہوں؟

ریموٹ پری چیک میں شامل ہونا چاہیے:

• شناخت ربط
• تصویر یا مساوی شناخت باندھنے والا عنصر
• متعلقہ گاڑی زمرہ
• اجراء اور میعاد ختم ہونے کی تاریخیں
• موجودہ میعاد
• ممکنہ طور پر عمر کی حد یا عمر کا بینڈ

پک اپ کو تصدیق کرنی چاہیے:

• حامل وہی شخص ہے جس نے پری چیک مکمل کیا
• موجودہ میعاد
• متعلقہ استحقاقات

بطور ڈیفالٹ ضروری نہیں:

• مکمل گھر کا پتہ جب بکنگ پروفائل میں پہلے سے رابطہ تفصیلات موجود ہوں
• مکمل تاریخ پیدائش جہاں عمر سے زیادہ یا عمر بینڈ کافی ہو
• غیر متعلق شناختی صفات
• مکمل اسناد کی دوبارہ پیشکش اگر بکنگ تصدیق پہلے سے موجود ہو

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

3. آجر: ایک تصدیق کنندہ زمرہ، مکمل شناخت میں داخلہ نہیں

W3C کا جائزہ ایک آجر کے ڈیجیٹل نظام کو یونیورسٹی ڈگری کی جانچ کرنے والے تصدیق کنندہ مثال کے طور پر استعمال کرتا ہے۔ یہ ہمیں یاد دلاتا ہے کہ آجر کی تصدیق پہلے ہی اسناد ماحولیاتی نظام میں ایک تسلیم شدہ نمونہ ہے۔

ایک آجر یا فلیٹ آپریٹر کو جاننے کی جائز ضرورت ہو سکتی ہے:

• کیا کوئی کارکن فی الحال کچھ گاڑی زمروں کو چلانے کا مستحق ہے
• کیا اہم پابندیاں موجود ہیں
• کیا استحقاق درست رہتا ہے

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

NIST خبردار کرتا ہے کہ دوبارہ استعمال کے قابل شناخت کار کو بار بار منتقل کرنا اور صارفین کو شناخت حامل اسناد بار بار پیش کرنے کی عادت ڈالنا ناپسندیدہ ہے، اور کہتا ہے کہ روزانہ کی توثیق پاس کیز جیسی توثیق کے لیے ڈیزائن کردہ ٹیکنالوجیز پر انحصار کرنی چاہیے۔ NIST سرور سائیڈ بائیو میٹرک ملاپ پر مقامی ڈیوائس توثیق کو ترجیح دیتا ہے کیونکہ یہ رازداری کو بہتر طریقے سے محفوظ رکھتی ہے۔

مستقبل کا IDP کام کی جگہ رسائی بیج نہیں بننا چاہیے۔

آجر اور فلیٹ استعمال کے لیے، درست نمونہ عام طور پر یہ ہے:

• ملازمت سے متعلق استحقاق جانچ
• شاید ایک متواتر تعمیل تصدیق
• شاید ایک دعوی کہ حامل مخصوص زمروں کے لیے درست رہتا ہے
• لیکن ہر بار جب ملازم کسی سسٹم میں سائن ان کرے یا شفٹ شروع کرے، تمام لائسنس ڈیٹا کی ڈیفالٹ منتقلی نہیں

فلیٹ تعمیل ایک الگ انحصار کرنے والی فریق زمرہ ہے، ایک الگ مطلوبہ استعمال کے ساتھ، اور ایک الگ افشاء پروفائل کے ساتھ۔

4. بیمہ کار: دعوے مسلسل نظرآوری کی اجازت نہیں

بیمہ کا معاملہ اکثر حقیقی ہوتا ہے۔ یورپی یونین mDL استعمال کیس مواد میں، بیمہ کار بالواسطہ طور پر کرایہ منظرنامے میں ظاہر ہوتے ہیں: بیمہ کمپنیاں کار کرایہ کمپنیوں سے یہ جانچنے کا مطالبہ کرتی ہیں کہ آیا گاڑی کرایے پر لینے والے شخص کو گاڑی چلانے کا حق ہے۔ بیمہ پہلے ہی ڈرائیونگ تصدیق بہاؤ کو متاثر کرتا ہے۔

لیکن اس کا مطلب یہ نہیں کہ بیمہ کار کو پولیس جیسا ڈیٹا ملنا چاہیے، یا اسناد تک مستقل رسائی کا حق ہو۔

مستقبل کا IDP بیمہ کاروں کو الگ مطلوبہ استعمال کے ساتھ ایک الگ تصدیق کنندہ زمرے کے طور پر دیکھنا چاہیے:

• انڈررائٹنگ
• کرایہ خطرے کی تصدیق
• نقصان کے بعد دعوے کی ہینڈلنگ
• دھوکہ دہی جائزہ

یہ ایک جیسے مقصد نہیں ہیں۔ یورپی یونین ڈیٹا تحفظ اصولوں کے تحت، ذاتی ڈیٹا مخصوص مقاصد کے لیے اکٹھا کیا جانا چاہیے اور اس مقصد کے لیے ضروری اور متناسب تک محدود ہونا چاہیے۔ W3C کی VC رہنمائی تکنیکی طور پر اسی نتیجے پر پہنچتی ہے: تصدیق کنندگان کو صرف وہی مانگنا چاہیے جو سختی سے ضروری ہو۔

جائز، واقعہ مخصوص مثالیں:

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

بطور ڈیفالٹ اجازت نہیں:

• بنیادی اسناد تک مستقل رسائی
• ہر بار جب گاہک بیمہ کار سے بات چیت کرے، عام تصدیق کا اعادہ
• ڈرائیونگ اسناد کو لاگ ان ٹوکن کے طور پر استعمال
• غیر متعلق صفات کا مجموعہ

ڈرائیونگ اسناد نگرانی کی رکنیت نہیں ہے۔ اور اسے چپکے سے ایسی نہیں بننی چاہیے۔

درمیانی فریقین کا نظر آنا کیوں ضروری ہے

حقیقی بازاروں میں درمیانی فریقین شامل ہوتے ہیں۔ کرایہ پلیٹ فارمز، فلیٹ وینڈرز، آجر HR سسٹمز، اور بیمہ دعوے پروسیسرز اکثر تیسری فریقین کے ذریعے کام کرتے ہیں۔

EUDI فن تعمیر اسے اس طرح سنبھالتا ہے:

• درمیانی فریقین کو انحصار کرنے والی فریقین کے طور پر سمجھنا
• انہیں رجسٹر کرنے کی ضرورت
• درمیانی انحصار کرنے والی فریق کے لیے مطلوبہ صفات کو رجسٹر کرنے کی ضرورت
• صارف کو درمیانی فریق اور آخری انحصار کرنے والی فریق دونوں دکھانا
• درمیانی فریقین کو لین دین کے مواد کے بارے میں ڈیٹا ذخیرہ کرنے سے منع کرنا

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

ETSI یہاں مدد کرتا ہے۔ اس کے والٹ-انحصار-فریق سرٹیفکیٹ ماڈل میں سپورٹ URIs، مطلوبہ استعمال، رجسٹری URIs، اور نگران اتھارٹی میٹا ڈیٹا شامل ہے۔ یہ مشین پڑھنے کے قابل انفراسٹرکچر کی قسم ہے جو صارفین کو یہ سمجھنے کے لیے ضروری ہے کہ درخواست کے دوسرے سرے پر اصل میں کون ہے اور جب وہ حذف یا تصحیح چاہتے ہیں تو کہاں جانا ہے۔

برقراری رسائی کنٹرول کا حصہ ہے

منتخب افشاء کے بارے میں زیادہ تر گفتگو بہت جلد ختم ہو جاتی ہے۔ وہ اس پر توجہ دیتے ہیں جو افشاء کیا جاتا ہے۔ وہ اس پر کافی توجہ نہیں دیتے کہ یہ بعد میں کتنی دیر تک رہتا ہے۔

موجودہ رہنمائی پہلے ہی یکجا ہو رہی ہے:

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

برقراری درجہ خود افشاء پالیسی کا حصہ ہونا چاہیے:

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

ایک مستقبل کا IDP جو برقراری کو نظرانداز کرے صرف جزوی طور پر رازداری محفوظ کرنے والا ہے۔

والٹ کو اصل میں کیا فیصلہ کرنا چاہیے

اگر مجھے اس پورے مضمون کو ایک نفاذ اصول تک کم کرنا ہو، تو یہ یہ ہوگا:

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

وہ فیصلہ کم از کم ان آدانوں سے کیا جانا چاہیے:

• تصدیق کنندہ شناخت
• تصدیق کنندہ زمرہ
• مطلوبہ استعمال
• رجسٹرڈ صفت دائرہ
• جاری کنندہ کی افشاء پالیسی، اگر موجود ہو
• ماحول (سڑک کنارہ، پک اپ، ریموٹ، فلیٹ، دعوی)
• حامل منظوری
• قابل اطلاق برقراری پالیسی

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

بنیادی دلیل

مستقبل کا IDP یہ نہیں پوچھنا چاہیے کہ آیا ڈیٹا افشاء کیا جا سکتا ہے۔ اسے پوچھنا چاہیے:

• کون پوچھ رہا ہے؟
• کس مقصد کے لیے؟
• کس اتھارٹی کے تحت؟
• کس سیاق و سباق میں؟
• کس برقراری نتائج کے ساتھ؟

پولیس، کرایہ ڈیسک، آجر، اور بیمہ کار درخواست کے دوسرے سرے پر چار لوگو نہیں ہیں۔ وہ چار مختلف خطرے کے ماڈل، چار مختلف قانونی سیاق و سباق، پوچھنے کی چار مختلف وجوہات ہیں — اور انہیں چار مختلف افشاء سیٹ پیدا کرنے چاہئیں۔

یہ غیر ضروری پیچیدگی نہیں ہے۔ ایک جدید ڈرائیونگ اسناد اس طرح نظر آتی ہے جب یہ ہر تصدیق کنندہ کو ایک جیسا تصدیق کنندہ سمجھنا بند کر دیتی ہے۔