معیارات · موبائل ڈرائیور لائسنس (mDL)

موبائل ڈرائیور لائسنس QR کوڈز: ISO/IEC 18013-5

جب کوئی بارٹینڈر، TSA افسر، یا کار کرایے پر دینے والا کلرک آپ کے فون کی ڈرائیور-لائسنس ایپ پر QR اسکین کرتا ہے، تو وہ QR لائسنس نہیں ہے۔ یہ ایک ہینڈشیک ہے۔ اصل خصوصیات صرف اس کے بعد سفر کرتی ہیں جب ان کا تصدیق کنندہ مخصوص فیلڈز مانگتا ہے اور آپ اپنے فون پر اجرا کی منظوری دیتے ہیں۔ صحیح طریقے سے کیا جائے، تو ایک mDL پلاسٹک کارڈ کے مقابلے میں بہت کم رساؤ کرتا ہے۔ غلط طریقے سے کیا جائے (دشمن تصدیق کنندہ، اندھا دھند منظوری)، تو یہ اتنا ہی یا اس سے زیادہ رساؤ کرتا ہے۔ فرق بتانے کا طریقہ یہ ہے۔

ایک mDL QR کا معائنہ کریں → تمام معیارات →

معیار کیا ہے

ISO/IEC 18013-5:2021، ذاتی شناخت، ISO-مطابق ڈرائیونگ لائسنس، حصہ 5: موبائل ڈرائیونگ لائسنس (mDL) ایپلی کیشن۔ وہ بین الاقوامی معیار جو بیان کرتا ہے کہ ڈیجیٹل ڈرائیور لائسنس کیسے جاری کیے، ذخیرہ کیے، verifier کو منتقل کیے، اور آف لائن تصدیق کیے جاتے ہیں۔ QR کوڈ سطح (وہ حصہ جو زیادہ تر لوگ دیکھتے ہیں) دفعہ 8.2 "Device retrieval، QR code engagement" ہے۔ ساتھی معیار ISO/IEC 18013-7 آن لائن بازیافت کا احاطہ کرتا ہے (verifier holder کی رضامندی سے issuer سے براہ راست پوچھتا ہے)۔

اپنانے کا عمل بھرپور طریقے سے جاری ہے: ایک درجن امریکی ریاستوں کے پاس Apple Wallet اور Google Wallet میں پروڈکشن میں جاری کیے جانے والے یا پائلٹ mDLs موجود ہیں؛ California کا mDL عام دستیابی میں ہے؛ TSA زیادہ تر بڑے امریکی ہوائی اڈوں پر سیکیورٹی پر mDLs قبول کرتا ہے؛ EU اپنی قسم کو eIDAS 2.0 کے تحت EUDI Wallet میں شامل کر رہا ہے (ضابطہ 2024 کے آخر میں نافذ، wallets 2026-2027 میں متوقع)۔ یہ معیار ISO/IEC 23220 (عمومی موبائل-کریڈنشل فریم ورک، جو ڈرائیور لائسنس سے آگے کی چیزوں کا احاطہ کرتا ہے) کی بنیاد بھی ہے۔

QR کے اندر دراصل کیا ہے

mDL QR ایک DeviceEngagement CBOR ڈھانچے کو انکوڈ کرتا ہے۔ CBOR (Concise Binary Object Representation، RFC 8949) JSON کا ایک کمپیکٹ بائنری متبادل ہے۔ ڈی کوڈ شدہ ڈھانچہ تقریباً اس طرح نظر آتا ہے:

{
  0: "1.0",                         // version
  1: [1, 2, [eDeviceKey bytes]],    // security: cipher suite 1, EC P-256 key
  2: [                              // device retrieval methods
    [1, 1, {...NFC options...}],
    [2, 1, {...BLE options...}],
    [3, 1, {...Wi-Fi Aware options...}]
  ],
  3: {...optional server retrieval...}
}

اہم فیلڈز، ڈی کوڈ شدہ:

ورژن

موجودہ تعیناتیوں کے لیے ہمیشہ “1.0”۔ مستقبل کی نظر ثانیاں اسے بڑھا سکتی ہیں۔

سائفر سوٹ

فی الحال ہمیشہ 1: P-256 پر ECDH کلید معاہدہ، AES-GCM سیشن انکرپشن۔ سائفر سوٹ 2 brainpoolP320r1 (EU استعمال کے معاملات) کے لیے مختص ہے۔

eDeviceKey

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

منتقلی کے طریقے

والیٹ تصدیق کنندہ کو بتاتا ہے کہ وہ اصل خصوصیت منتقلی کے لیے کون سے چینلز استعمال کرنے کے لیے تیار ہے: NFC (ٹیپ)، Bluetooth LE، یا Wi-Fi Aware (رسائی پوائنٹ کے بغیر پیئر-ٹو-پیئر Wi-Fi)۔ زیادہ تر mDL، BLE اور NFC پیش کرتے ہیں؛ Wi-Fi Aware پلیٹ فارم کے لحاظ سے محدود ہے۔

سرور بازیافت (اختیاری)

اگر موجود ہو، تو والیٹ 18013-7 موڈ کی حمایت کرتا ہے: تصدیق کنندہ والیٹ سے براہ راست کے بجائے جاری کنندہ کے آن لائن API سے خصوصیات کی درخواست کر سکتا ہے۔ QR میں جاری کنندہ کا URL شامل ہوتا ہے۔ ہمارا اسکینر اسے نکالتا ہے اور آپ کو دکھاتا ہے کہ کون سی اتھارٹی استفسار وصول کرے گی۔

یہ پلاسٹک کارڈ پر AAMVA PDF417 سے کیسے مختلف ہے؟

یہ credential کی مختلف قسم ہے۔ امریکی پلاسٹک لائسنس کی پشت پر موجود AAMVA PDF417 بارکوڈ کارڈ کی ہر صفت سادہ متن میں رکھتا ہے — نام، پتہ، DOB، لائسنس نمبر، قد، وزن، آنکھ کا رنگ، پابندیاں، اعضاء عطیہ کرنے کا نشان۔ کوئی بھی اسکینر سب کچھ پڑھ سکتا ہے۔ کارڈ ایک "سب یا کچھ نہیں" credential ہے: یا تو آپ اسے دیتے ہیں اور سب ظاہر کرتے ہیں، یا نہیں دیتے۔

mDL اسے الٹ دیتا ہے۔ QR میں کوئی صفات نہیں، صرف ایک handshake ہے۔ verifier کو مخصوص صفات مانگنی ہوتی ہیں (given_name، family_name، birth_date، age_over_21، portrait، document_number، driving_privileges، وغیرہ) — والٹ آپ کو درخواست دکھاتا ہے، اور صرف وہی صفات منتقل ہوتی ہیں جن کی آپ منظوری دیتے ہیں۔ منتقلی جاری کرنے والے ادارے (آپ کی ریاستی DMV) کے ذریعے کرپٹوگرافی سے دستخط شدہ بھی ہوتی ہے، اس لیے verifier تصدیق کر سکتا ہے کہ صفات اصلی ہیں بغیر فون کیے — آف لائن تصدیق کام کرتی ہے۔

یہی وجہ ہے کہ رازداری کی پروا کرنے والے لوگ mDLs کو ترجیح دیتے ہیں حالانکہ معیار زیادہ پیچیدہ ہے: یہ لین دین کے دائرے تک محدود انکشاف قابل بناتا ہے۔ ایک باؤنسر کو آپ کے پتے کی ضرورت نہیں؛ TSA افسر کو آپ کی اعضاء عطیہ کی حیثیت کی ضرورت نہیں؛ 7-Eleven ملازم کو آپ کے لائسنس نمبر کی ضرورت نہیں۔

انتخابی انکشاف: اصل نقطہ

mDL معیار derived attributes کا ایک سیٹ متعین کرتا ہے جو verifier کو خام قدر کی بجائے ہاں/نہیں سوال پوچھنے دیتا ہے۔ بڑے سوالات:

کسی بار کے لیے اچھی طرح ڈیزائن کردہ verifier ایپ صرف age_over_21 مانگتی ہے۔ والٹ دکھاتا ہے "Bar XYZ جاننا چاہتا ہے کہ آیا آپ 21 سال سے بڑے ہیں۔" آپ Approve ٹیپ کرتے ہیں، ایک دستخط شدہ boolean ("true") واپس جاتا ہے۔ بار کی ایپ آپ کی ریاست کے شائع شدہ mDL trust root کے خلاف دستخط تصدیق کرتی ہے۔ بس۔ نہ DOB، نہ نام، نہ لائسنس نمبر، نہ تصویر۔ پلاسٹک کارڈ دینے کے مقابلے میں یہ رازداری کا بہت بڑا فائدہ ہے۔

دشمن verifiers: نیا خطرے کا نمونہ

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

کوئی بھی تصدیق کنندہ ایپ بنا سکتا ہے۔ کوئی مرکزی لائسنسنگ اتھارٹی نہیں ہے۔ تو ایک بار اسٹاک سے دستیاب تصدیق کنندہ چلا سکتا ہے جو مکمل DOB، مکمل نام، اور تصویر مانگنے کے لیے ترتیب دیا گیا ہو حالانکہ اسے صرف age_over_21 کی ضرورت ہوتی ہے۔ کار کرایے پر دینے والا کلرک “فائل کے لیے” سب کچھ مانگ سکتا ہے۔ کوئی ریٹیل کلرک پتہ مانگ سکتا ہے۔ ان میں سے کوئی بھی تکنیکی طور پر معیار کے ذریعے ممنوع نہیں ہے، معیار صرف یہ کہتا ہے کہ والیٹ کو حامل کو دکھانا ہوگا کہ کیا مانگا جا رہا ہے اور واضح منظوری لازمی بنانی ہوگی۔

لہذا دفاع holder کی طرف ہے: درخواست کا پرامپٹ پڑھیں۔ اگر verifier لین دین کی ضرورت سے زیادہ مانگ رہا ہے تو انکار کریں۔ کچھ والٹس خبردار کرتے ہیں جب verifier کسی معلوم trust list میں نہ ہو؛ ISO/IEC 18013-5 سرٹیفکیٹس کے ذریعے verifier تصدیق کی سپورٹ کرتا ہے، لیکن trust-list انفراسٹرکچر ابھی پختہ ہو رہا ہے (امریکہ میں ریاستی فہرستیں؛ eIDAS 2.0 کے تحت EU trust list)۔

یہ بھی جاننا ضروری ہے: verifier آپ کا eDeviceKey، cipher suite، اور وہ transfer methods دیکھتا ہے جن کی آپ سپورٹ کرتے ہیں — بس یہی۔ انہیں صرف QR سے کوئی صفات نہیں ملتے۔ اس لیے کسی اسٹیکر یا کسی کی اسکرین سے QR اسکین کر کے چلے جانا کسی حملہ آور کو کچھ کارآمد نہیں دیتا۔ صفات صرف handshake کے بعد خفیہ سیشن کے اندر منتقل ہوتے ہیں۔

ہمارا اسکینر آپ کو کیا دکھاتا ہے

ہمارے اسکینر میں mDL DeviceEngagement QR (تصویر، پیسٹ، یا کیمرہ) ڈالیں۔ نتیجہ دکھاتا ہے:

ہم کوئی صفات ڈی کوڈ نہیں کرتے — ڈیزائن کے لحاظ سے QR میں کوئی صفات ہوتے ہی نہیں۔ اصل لائسنس ڈیٹا ایک حقیقی verifier کو منتخب transfer method کے ذریعے خفیہ کر کے بھیجا جائے گا۔

ڈی کوڈنگ آپ کے براؤزر میں ہوتی ہے؛ حفاظتی درجہ بندی کے لیے صرف ساختی میٹا ڈیٹا ہمارے سرور تک پہنچتا ہے۔

تصدیق کنندہ کی درخواست منظور کرنے سے پہلے

متعلقہ

ایک mDL DeviceEngagement QR کا معائنہ کریں

QR ڈراپ کریں (تصویر، پیسٹ، یا کیمرہ)۔ فیصلہ ورژن، سائفر سوٹ، منتقلی کے طریقے، اور کوئی بھی اختیاری سرور-بازیافت URL دکھاتا ہے۔ کوئی خصوصیات نہیں، وہ صرف انکرپٹڈ پوسٹ-ہینڈشیک سیشن کے اندر ایک حقیقی تصدیق کنندہ تک سفر کرتی ہیں۔

اسکینر کھولیں →