পুলিশ, রেন্টাল ডেস্ক, নিয়োগকর্তা, বীমাকারী: কেন তারা একই তথ্য দেখতে পাবে না

ভবিষ্যতের আন্তর্জাতিক ড্রাইভিং পারমিটের (IDP) সবচেয়ে বড় ডিজাইন ভুল হবে প্রতিটি যাচাইকারীকে একই যাচাইকারী হিসেবে বিবেচনা করা। একজন পুলিশ কর্মকর্তা, একটি কার রেন্টাল ডেস্ক, একজন নিয়োগকর্তা এবং একজন বীমাকারী একই প্রশ্ন করেন না — তাই তাদের একই উত্তর পাওয়া উচিত নয়।

একজন চালক। গাড়ি চালানোর একটি মৌলিক অধিকার। একটি ওয়ালেট। কিন্তু চারটি সম্পূর্ণ ভিন্ন যাচাইকারী:

• রাস্তার পাশে একজন পুলিশ কর্মকর্তা
• গাড়ি তোলার সময় একটি কার রেন্টাল ডেস্ক
• ফ্লিট যোগ্যতা যাচাই করছেন এমন একজন নিয়োগকর্তা
• একটি দাবি পর্যালোচনা করছেন এমন একজন বীমাকারী

যদি ভবিষ্যতের IDP চারজনকে একই তথ্য দেখায়, তাহলে সিস্টেমটি ইতিমধ্যেই ব্যর্থ হয়েছে। শংসাপত্রটি অনিরাপদ বলে নয়, বরং প্রকাশের মডেলটি অতিমাত্রায় সরল বলে।

মানদণ্ড সম্প্রদায় ইতিমধ্যেই সেই সরল মডেল থেকে সরে আসছে। W3C-এর যাচাইযোগ্য-শংসাপত্র কাজ ইস্যুকারী, ধারক এবং যাচাইকারীদের চারপাশের ইকোসিস্টেম বর্ণনা করে, যাচাইকারীদের উদাহরণ হিসেবে নিয়োগকর্তা এবং ওয়েবসাইট ব্যবহার করে। ইইউ-এর মোবাইল ড্রাইভিং-লাইসেন্স কাজ ইতিমধ্যেই রাস্তার পাশের চেক এবং কার রেন্টালকে আলাদা যাচাইকরণ পরিস্থিতি হিসেবে বিবেচনা করে, যার মধ্যে রেন্টালের জন্য রিমোট অ্যাডভান্স শেয়ারিং এবং পুলিশের জন্য ব্যক্তিগত চেক অন্তর্ভুক্ত। আর্কিটেকচারটি ইতিমধ্যেই একাধিক যাচাইকারীর ধরনের জন্য ডিজাইন করা হয়েছে। ভুলটি হবে ব্যবহারকারীর অভিজ্ঞতা এমনভাবে ডিজাইন করা যেন শুধুমাত্র একটি ধরন বিদ্যমান।

কেন ফিজিক্যাল কার্ড আমাদের ভুলভাবে ভাবতে শিখিয়েছে

একটি ফিজিক্যাল লাইসেন্স আমাদের সব-দেখানোর পদ্ধতিতে অভ্যস্ত করে তুলেছে। আপনি কার্ডটি হস্তান্তর করেন। অপর ব্যক্তি কার্ডে যা আছে তা দেখেন। এটাই পুরো মিথস্ক্রিয়া।

একটি কাগজের জগতে এই পদ্ধতি গ্রহণযোগ্য কারণ কোনো বিকল্প নেই। একটি ডিজিটাল জগতে এটি অগ্রহণযোগ্য হয়ে ওঠে।

W3C VC ডেটা মডেল ২.০ সরাসরি বলে: একটি ড্রাইভারের লাইসেন্সে আইডি নম্বর, উচ্চতা, ওজন, জন্মদিন এবং বাড়ির ঠিকানা থাকতে পারে — কিন্তু একটি নির্দিষ্ট লেনদেনের জন্য এটি এখনও প্রয়োজনের চেয়ে অনেক বেশি হতে পারে। বর্তমান মানদণ্ড থেকে মূল বিষয়গুলো:

• W3C সর্বোত্তম অনুশীলন: নির্বাচনী প্রকাশ সমর্থন করুন, এবং শুধুমাত্র যা একেবারে প্রয়োজনীয় তা অনুরোধ করুন
• ইইউ ডেটা-সুরক্ষা নির্দেশিকা: প্রক্রিয়াকরণ অবশ্যই নির্দিষ্ট উদ্দেশ্যে সীমাবদ্ধ হতে হবে, এবং প্রক্রিয়াকৃত ডেটা অবশ্যই প্রয়োজনীয় ও আনুপাতিক হতে হবে
• ভবিষ্যত IDP-এর প্রথম নীতি: একই শংসাপত্র মানেই পরিদর্শনের একই অধিকার নয়

সঠিক মডেল হলো নীতি-ভিত্তিক প্রকাশ

আপনি যদি একটি গুরুতর আর্কিটেকচার চান, তাহলে সঠিক মডেলটি ডিজিটাল কার্ড উপস্থাপনার চেয়ে অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণের কাছাকাছি।

NIST SP 800-205 অ্যাক্সেস-নিয়ন্ত্রণ সিদ্ধান্তগুলোকে নীতির বিপরীতে বিষয়, বস্তু, অনুরোধকৃত অপারেশন এবং পরিবেশগত অবস্থার সাথে সম্পর্কিত অ্যাট্রিবিউটগুলোর মূল্যায়ন হিসেবে সংজ্ঞায়িত করে। ভবিষ্যতের IDP-এর জন্য এটিই হলো সঠিক কাঠামো:

• বিষয়: চালক
• বস্তু: অনুরোধকৃত ডেটা ফিল্ড
• ক্রিয়া: বিমূর্তভাবে “লাইসেন্স দেখুন” নয়, বরং নির্দিষ্ট কিছু যেমন “রাস্তার পাশে বি ক্যাটাগরি চালানোর অধিকার যাচাই করুন” বা “একটি বুকিংয়ের জন্য রেন্টাল যোগ্যতা যাচাই করুন”
• পরিবেশ: রাস্তার পাশ, রেন্টাল ডেস্ক, রিমোট প্রি-চেক, ফ্লিট অনবোর্ডিং এবং ক্ষতি-পরবর্তী দাবি পর্যালোচনা ভিন্ন পরিবেশ এবং ভিন্ন সিদ্ধান্তের দিকে নিয়ে যাওয়া উচিত

NIST আরো উল্লেখ করে যে অ্যাট্রিবিউট সিস্টেমের সূক্ষ্মতা, শাসন এবং অ্যাট্রিবিউট হ্রাস, গ্রুপিং ও ন্যূনীকরণের জন্য প্রক্রিয়া প্রয়োজন।

তাই ভবিষ্যতের IDP-এর জিজ্ঞাসা করা উচিত নয়: এই যাচাইকারী কি লাইসেন্স পড়তে পারে? বরং জিজ্ঞাসা করা উচিত: এই যাচাইকারী কোন উদ্দেশ্যে, কোন পরিবেশে, কোন ধারণ বিধির অধীনে কোন দাবিগুলো পেতে পারে?

একটি যাচাইকারীর উচিত কিছু অনুরোধ করার আগে নিজেকে পরিচয় করিয়ে দেওয়া

ভবিষ্যতের IDP-এর শুরু হওয়া উচিত ওয়ালেট ডেটা দেখানো দিয়ে নয়। শুরু হওয়া উচিত যাচাইকারী তার পরিচয় প্রমাণ করা দিয়ে।

EUDI আর্কিটেকচার এ বিষয়ে স্পষ্ট। নির্ভরকারী পক্ষগুলোকে অবশ্যই:

• তারা কোন অ্যাট্রিবিউট অনুরোধ করতে চায় এবং কী উদ্দেশ্যে তা নিবন্ধন করতে হবে
• অ্যাক্সেস সার্টিফিকেট গ্রহণ করতে হবে
• যেকোনো প্রকাশের আগে ওয়ালেটে প্রমাণীকরণ করতে হবে
• নিবন্ধন তথ্য পাওয়া গেলে তাদের নিবন্ধিত সুযোগের বিপরীতে যাচাই করতে হবে

ব্যবহারকারী তখন দেখতে পাবেন কে জিজ্ঞাসা করছে, কী চাওয়া হচ্ছে এবং অনুরোধটি নিবন্ধিত সুযোগের মধ্যে কিনা।

ETSI-এর বর্তমান ওয়ালেট-নির্ভরকারী-পক্ষ সার্টিফিকেট কাজ এটিকে আরো সুনির্দিষ্ট করে তোলে। একটি ওয়ালেট-নির্ভরকারী-পক্ষ নিবন্ধন সার্টিফিকেট নির্ভরকারী পক্ষের উদ্দেশ্যমূলক ব্যবহার এবং এটি অনুরোধ করার জন্য নিবন্ধিত অ্যাট্রিবিউটগুলো বর্ণনা করতে পারে। সংশ্লিষ্ট অ্যাক্সেস সার্টিফিকেট নিশ্চিত করতে বিদ্যমান যে অনুরোধটি একটি বৈধ, অনুমোদিত পক্ষ থেকে আসে। ETSI নির্ভরকারী-পক্ষের মেটাডেটাও অন্তর্ভুক্ত করে যেমন:

• ট্রেড নাম
• সাপোর্ট URI
• উদ্দেশ্যমূলক ব্যবহার
• এনটাইটেলমেন্ট
• রেজিস্ট্রি URI
• তত্ত্বাবধায়ক-কর্তৃপক্ষের তথ্য

ভবিষ্যতের IDP-এর দ্বিতীয় নীতি: যাচাইকারীর পরিচয় নেই, প্রকাশ নেই।

কেন সম্মতি স্ক্রিন যথেষ্ট নয়

এখানে আরেকটি ভুল আছে: ব্যবহারকারীর অনুমোদনকে আইনি বৈধতার মতো একই জিনিস হিসেবে বিবেচনা করা।

EUDI আর্কিটেকচার স্পষ্টভাবে বলে যে অ্যাট্রিবিউট উপস্থাপনের জন্য ব্যবহারকারীর অনুমোদনকে নির্ভরকারী পক্ষের ব্যক্তিগত তথ্য প্রক্রিয়াকরণের আইনি ভিত্তি হিসেবে বিবেচনা করা উচিত নয়। নির্ভরকারী পক্ষের নিজস্ব আইনি ভিত্তি থাকতে হবে। EUDI সমস্ত ব্যবহারের ক্ষেত্রে ব্যবহারকারীর অনুমোদনের প্রয়োজনীয়তাও রাখে, এমন ক্ষেত্রগুলোতেও যেখানে নির্ভরকারী পক্ষ আইন প্রয়োগকারী বা অন্য কোনো সরকারি সংস্থার অংশ হতে পারে।

একটি ভালো ওয়ালেট ইন্টারফেস সাহায্য করতে পারে, কিন্তু এটি একা যাচাইকারীর অতিমাত্রায় অনুরোধ সমস্যা সমাধান করতে পারে না। নিয়মটি ইন্টারফেসের আগে থাকতে হবে।

ভবিষ্যতের IDP-এর তাই উভয়ের প্রয়োজন:

• ক্রিপ্টোগ্রাফিক যাচাইকারী প্রমাণীকরণ কে জিজ্ঞাসা করছে তা নিশ্চিত করতে
• নীতি সীমাবদ্ধতা সেই যাচাইকারী বিভাগ কী অনুরোধ করতে পারে তার উপর

উভয় ছাড়া, “ব্যবহারকারীর পছন্দ” ব্যক্তির উপর নীতিগত ব্যর্থতা চাপানোর একটি উপায় হয়ে ওঠে।

১. পুলিশ: গাড়ি চালানোর অধিকার যাচাই করুন, পুরো ব্যক্তি নয়

পুলিশের রাস্তার পাশের পরিস্থিতি সবচেয়ে কেন্দ্রীভূত।

ইইউ mDL ম্যানুয়াল এটি সরাসরি বর্ণনা করে: পুলিশ বা অন্যান্য কর্মকর্তারা প্রয়োজনে লাইসেন্স যাচাই করেন, যার মধ্যে লাইসেন্সের বৈধতা এবং যানবাহনের এনটাইটেলমেন্ট অন্তর্ভুক্ত। ব্যবহারকারীর যাত্রায়, কর্মকর্তা QR-ট্রিগারড ফ্লো, ব্লুটুথ, Wi-Fi Aware বা NFC-এর মাধ্যমে লাইসেন্স যাচাই করেন। এটি একটি কেন্দ্রীভূত যাচাইকরণ কাজ:

• এই ব্যক্তি কি ধারক?
• শংসাপত্রটি কি বৈধ?
• কোন যানবাহন এনটাইটেলমেন্ট এবং বিধিনিষেধ প্রযোজ্য?

ডিফল্টভাবে অনুমোদিত:

• নাম
• ছবি
• লাইসেন্সের অবস্থা
• ইস্যু এবং মেয়াদ শেষের তারিখ
• বিভাগ
• ড্রাইভিং-সংক্রান্ত বিধিনিষেধ
• ইস্যুকারী এবং এখতিয়ার
• তাজা/অবস্থার ফলাফল

ডিফল্টভাবে অনুমোদিত নয়:

• বাড়ির ঠিকানা
• রাস্তার পাশের ব্যবহারের জন্য অপ্রয়োজনীয় অভ্যন্তরীণ পরিচয়কারী
• অন্যান্য প্রত্যয়ন থেকে অসম্পর্কিত অ্যাট্রিবিউট
• ঐতিহাসিক উপস্থাপনা লগ
• বাণিজ্যিক মেটাডেটা

AAMVA-এর বাস্তবায়ন নির্দেশিকা ছবির বিষয়টি নিশ্চিত করে: ছবি অনুরোধ করা হলে এবং অন্য কোনো উপাদান প্রকাশিত হলে, যাচাইকারী যাতে উপাদানগুলোকে উপস্থাপনকারী ব্যক্তির সাথে সংযুক্ত করতে পারেন তার জন্য ছবি শেয়ার করা উচিত। একই নির্দেশিকা আরো বলে যে স্টেকহোল্ডাররা আইন দ্বারা প্রয়োজনীয় ক্ষেত্র ছাড়া mDL ধারক বা mDL ব্যবহার ট্র্যাক করবেন না।

পুলিশের ক্ষেত্রটি রাষ্ট্রের সবকিছু পাওয়ার বিষয়ে নয়। এটি রাস্তার পাশের প্রয়োগের জন্য প্রয়োজনীয় ড্রাইভিং-নির্দিষ্ট ডেটা পাওয়ার বিষয়ে। এটি একটি গুরুত্বপূর্ণ পার্থক্য।

২. রেন্টাল ডেস্ক: যোগ্যতা, পরিচয় মিল এবং অপ্রয়োজনীয় কিছু নয়

রেন্টালের ক্ষেত্রটি আরো বিস্তারিত কারণ সত্যিকার অর্থে দুটি মুহূর্ত আছে: আগমনের আগে রিমোট প্রি-চেক এবং পিকআপের সময় যখন কোনো ব্যক্তি বা কিওস্ক চাবি হস্তান্তর করে।

ইইউ mDL ম্যানুয়াল ইতিমধ্যেই উভয় মডেল করে। একটি কার-রেন্টাল সেবা বুকিংয়ের সময় পরিচয়ের প্রমাণের পাশাপাশি mDL অনুরোধ করতে পারে, প্রত্যয়নগুলো যাচাই করতে পারে এবং পরে যানবাহন ছেড়ে দেওয়ার আগে পিকআপে ব্যক্তিগতভাবে গ্রাহককে যাচাই করতে পারে। ব্যবহারকারীরা ব্যক্তিগতভাবে বা আগে থেকে রিমোটলি কার-রেন্টাল কোম্পানিগুলোর সাথে তাদের mDL শেয়ার করতে পারেন।

একটি রেন্টাল ডেস্কের প্রাথমিকভাবে কোনো ঘটনা তদন্ত করার প্রয়োজন নেই। এটি সিদ্ধান্ত নিতে হবে: আমি কি এই বুকিং এবং নীতির অধীনে এই গ্রাহককে এই যানবাহন ভাড়া দিতে পারি?

রিমোট প্রি-চেকে অন্তর্ভুক্ত হওয়া উচিত:

• পরিচয় সংযোগ
• ছবি বা সমতুল্য পরিচয়-বাইন্ডিং উপাদান
• প্রাসঙ্গিক যানবাহন বিভাগ
• ইস্যু এবং মেয়াদ শেষের তারিখ
• বর্তমান বৈধতা
• সম্ভবত একটি বয়স সীমা বা বয়স ব্যান্ড

পিকআপে নিশ্চিত করা উচিত:

• ধারক সেই একই ব্যক্তি যিনি প্রি-চেক সম্পন্ন করেছেন
• বর্তমান বৈধতা
• প্রাসঙ্গিক এনটাইটেলমেন্ট

ডিফল্টভাবে প্রয়োজন নেই:

• সম্পূর্ণ বাড়ির ঠিকানা যখন একটি বুকিং প্রোফাইলে ইতিমধ্যে যোগাযোগের বিবরণ রয়েছে
• সম্পূর্ণ জন্ম তারিখ যেখানে এজ-ওভার বা এজ-ব্যান্ড যথেষ্ট
• অসম্পর্কিত পরিচয় অ্যাট্রিবিউট
• বুকিং প্রত্যয়ন ইতিমধ্যেই থাকলে সম্পূর্ণ শংসাপত্রের পুনরাবৃত্তিমূলক পুনর-উপস্থাপনা

NIST-এর বর্তমান mDL আর্কিটেকচার দেখায় যে নির্ভরকারী পক্ষ শুধুমাত্র প্রয়োজনীয় অ্যাট্রিবিউট অনুরোধ করতে DCQL ব্যবহার করে, এবং স্পষ্টভাবে বলে এটি শংসাপত্রকে একক ইউনিট হিসেবে বিবেচনার পরিবর্তে অনুরোধটি কাঠামোগত করে ডেটা ন্যূনীকরণ এবং ধারক সম্মতি সমর্থন করে। AAMVA যোগ করে যে অ্যাপ্লিকেশনটি স্পষ্টভাবে দেখাতে হবে কোন ডেটা অনুরোধ করা হয়েছিল এবং যাচাইকারী তথ্য ধরে রাখতে চান কিনা।

৩. নিয়োগকর্তা: একটি যাচাইকারী বিভাগ, সম্পূর্ণ পরিচয়ে প্রবেশের সুযোগ নয়

W3C-এর ওভারভিউ একটি নিয়োগকর্তার ডিজিটাল সিস্টেম একটি বিশ্ববিদ্যালয় ডিগ্রি যাচাই করার উদাহরণ হিসেবে যাচাইকারীর উদাহরণ ব্যবহার করে। এটি আমাদের মনে করিয়ে দেয় যে নিয়োগকর্তার যাচাইকরণ শংসাপত্র ইকোসিস্টেমে ইতিমধ্যেই একটি স্বীকৃত প্যাটার্ন।

একজন নিয়োগকর্তা বা ফ্লিট অপারেটরের বৈধভাবে জানার প্রয়োজন হতে পারে:

• একজন কর্মীর বর্তমানে নির্দিষ্ট যানবাহন বিভাগ চালানোর অধিকার আছে কিনা
• মূল বিধিনিষেধ বিদ্যমান কিনা
• এনটাইটেলমেন্ট বৈধ কিনা

এটি একটি বাস্তব ব্যবসায়িক প্রয়োজন। কিন্তু এটি স্বয়ংক্রিয়ভাবে সম্পূর্ণ ড্রাইভিং শংসাপত্র, সম্পূর্ণ পরিচয় ডেটা বা বারবার উপস্থাপনার একটি অবিরাম স্ট্রিমে স্থায়ী অ্যাক্সেসকে ন্যায্যতা দেয় না।

NIST সতর্ক করে যে একটি পুনরায় ব্যবহারযোগ্য পরিচয়কারী ঘন ঘন প্রেরণ করা এবং ব্যবহারকারীদের বারবার একটি পরিচয়-বহনকারী শংসাপত্র উপস্থাপন করার শর্ত দেওয়া অবাঞ্ছনীয়, এবং বলে যে দৈনন্দিন প্রমাণীকরণের জন্য পাসকির মতো প্রমাণীকরণের জন্য ডিজাইন করা প্রযুক্তির উপর নির্ভর করা উচিত। NIST গোপনীয়তা আরো ভালোভাবে সংরক্ষণ করে বলে সার্ভার-সাইড বায়োমেট্রিক ম্যাচিংয়ের চেয়ে স্থানীয় ডিভাইস প্রমাণীকরণ পছন্দ করে।

ভবিষ্যতের IDP একটি কর্মক্ষেত্র অ্যাক্সেস ব্যাজ হওয়া উচিত নয়।

নিয়োগকর্তা এবং ফ্লিট ব্যবহারের জন্য, সঠিক প্যাটার্নটি সাধারণত:

• একটি কাজ-প্রাসঙ্গিক এনটাইটেলমেন্ট চেক
• সম্ভবত একটি পর্যায়ক্রমিক সম্মতি প্রত্যয়ন
• সম্ভবত একটি দাবি যে ধারক নির্দিষ্ট বিভাগের জন্য বৈধ থাকেন
• কিন্তু প্রতিবার কর্মী কোনো সিস্টেমে সাইন ইন করলে বা শিফট শুরু করলে সমস্ত লাইসেন্স ডেটার ডিফল্ট ট্রান্সফার নয়

ফ্লিট কমপ্লায়েন্স একটি পৃথক নির্ভরকারী-পক্ষ বিভাগ, একটি পৃথক উদ্দেশ্যমূলক ব্যবহার সহ এবং একটি পৃথক প্রকাশ প্রোফাইল সহ।

৪. বীমাকারী: দাবিগুলো ক্রমাগত দৃশ্যমানতার অনুমতি নয়

বীমার ক্ষেত্রটি প্রায়ই বাস্তব। ইইউ mDL ব্যবহার-কেস উপকরণে, বীমাকারীরা রেন্টাল পরিস্থিতিতে পরোক্ষভাবে প্রদর্শিত হন: বীমা কোম্পানিগুলো কার-রেন্টাল কোম্পানিগুলোকে যাচাই করতে বলে যে গাড়ি ভাড়া নেওয়া ব্যক্তির গাড়ি চালানোর অধিকার আছে কিনা। বীমা ইতিমধ্যেই ড্রাইভিং-যাচাইকরণ প্রবাহকে প্রভাবিত করে।

কিন্তু তার মানে এই নয় যে একজন বীমাকারী পুলিশের মতো একই ডেটা বা শংসাপত্রে স্থায়ী অ্যাক্সেসের অধিকার পাবেন।

ভবিষ্যতের IDP বীমাকারীদের পৃথক উদ্দেশ্যমূলক ব্যবহার সহ একটি পৃথক যাচাইকারী বিভাগ হিসেবে বিবেচনা করা উচিত:

• আন্ডাররাইটিং
• রেন্টাল-ঝুঁকি যাচাইকরণ
• ক্ষতি-পরবর্তী দাবি পরিচালনা
• জালিয়াতি পর্যালোচনা

এগুলো একই উদ্দেশ্য নয়। ইইউ ডেটা-সুরক্ষা নীতির অধীনে, ব্যক্তিগত ডেটা নির্দিষ্ট উদ্দেশ্যে সংগ্রহ করতে হবে এবং সেই উদ্দেশ্যের জন্য প্রয়োজনীয় ও আনুপাতিকে সীমাবদ্ধ রাখতে হবে। W3C-এর VC নির্দেশিকা প্রযুক্তিগতভাবে একই সিদ্ধান্তে পৌঁছায়: যাচাইকারীদের শুধুমাত্র একেবারে প্রয়োজনীয় জিনিস অনুরোধ করা উচিত।

বৈধ, ঘটনা-নির্দিষ্ট উদাহরণ:

• প্রমাণ যে লাইসেন্সটি প্রাসঙ্গিক মুহূর্তে বৈধ ছিল
• প্রাসঙ্গিক যানবাহন এনটাইটেলমেন্টের প্রমাণ
• দাবির জন্য প্রয়োজনীয় পরিচয় সংযোগের প্রমাণ
• দাবি-নির্দিষ্ট প্রকাশ

ডিফল্টভাবে অনুমোদিত নয়:

• অন্তর্নিহিত শংসাপত্রে স্থায়ী অ্যাক্সেস
• প্রতিবার গ্রাহক বীমাকারীর সাথে যোগাযোগ করলে বারবার সাধারণ যাচাইকরণ
• ড্রাইভিং শংসাপত্রকে লগইন টোকেন হিসেবে ব্যবহার
• অসম্পর্কিত অ্যাট্রিবিউট সংগ্রহ

একটি ড্রাইভিং শংসাপত্র একটি পর্যবেক্ষণ সাবস্ক্রিপশন নয়। এবং এটি নীরবে সেরকম হওয়া উচিত নয়।

কেন মধ্যস্থতাকারীরা দৃশ্যমান হতে হবে

বাস্তব বাজারে মধ্যস্থতাকারী থাকে। রেন্টাল প্ল্যাটফর্ম, ফ্লিট ভেন্ডার, নিয়োগকর্তার HR সিস্টেম এবং বীমা দাবি প্রসেসর প্রায়ই তৃতীয় পক্ষের মাধ্যমে কাজ করে।

EUDI আর্কিটেকচার এটি পরিচালনা করে:

• মধ্যস্থতাকারীদের নির্ভরকারী পক্ষ হিসেবে বিবেচনা করে
• তাদের নিবন্ধন করতে বাধ্য করে
• মধ্যস্থ নির্ভরকারী পক্ষের জন্য অনুরোধকৃত অ্যাট্রিবিউটগুলো নিবন্ধিত হতে বাধ্য করে
• ব্যবহারকারীর কাছে মধ্যস্থতাকারী এবং শেষ নির্ভরকারী পক্ষ উভয়কে দেখায়
• মধ্যস্থতাকারীদের লেনদেনের বিষয়বস্তু সম্পর্কে ডেটা সংরক্ষণ নিষিদ্ধ করে

ভবিষ্যতের IDP কখনই এমন একটি প্যাটার্নের অনুমতি দেওয়া উচিত নয় যেখানে ব্যবহারকারী বিশ্বাস করেন যে তারা রেন্টাল কোম্পানির কাছে প্রকাশ করছেন, কিন্তু বাস্তবে তারা একটি অদৃশ্য যাচাইকরণ ব্রোকার, বিশ্লেষণ প্রসেসর এবং দাবি ভেন্ডার চেইনের কাছে প্রকাশ করছেন।

ETSI এখানে সাহায্য করে। এর ওয়ালেট-নির্ভরকারী-পক্ষ সার্টিফিকেট মডেলে সাপোর্ট URI, উদ্দেশ্যমূলক ব্যবহার, রেজিস্ট্রি URI এবং তত্ত্বাবধায়ক-কর্তৃপক্ষের মেটাডেটার সমর্থন অন্তর্ভুক্ত। এটি সেই ধরনের মেশিন-পাঠযোগ্য অবকাঠামো যা ব্যবহারকারীদের বুঝতে সাহায্য করে যে অনুরোধের অন্য প্রান্তে আসলে কে আছে এবং তারা মুছে ফেলা বা সংশোধন চাইলে কোথায় যাবেন।

ধারণ অ্যাক্সেস নিয়ন্ত্রণের অংশ

নির্বাচনী প্রকাশ নিয়ে অধিকাংশ আলোচনা অনেক আগেই শেষ হয়ে যায়। তারা কী প্রকাশ করা হয় তার উপর মনোযোগ দেয়। তারা এরপর কতক্ষণ থাকে তার উপর যথেষ্ট মনোযোগ দেয় না।

বর্তমান নির্দেশিকা ইতিমধ্যেই একত্রিত হচ্ছে:

• AAMVA: ওয়ালেটকে অবশ্যই স্পষ্টভাবে ধারককে বলতে হবে কোন ডেটা অনুরোধ করা হয়েছিল এবং যাচাইকারী তথ্য ধরে রাখতে চান কিনা; স্টেকহোল্ডাররা আইন দ্বারা প্রয়োজনীয় ক্ষেত্র ছাড়া ধারক বা mDL ব্যবহার ট্র্যাক করবেন না
• W3C: ধারক সফ্টওয়্যারের যাচাইকারীদের সাথে শেয়ার করা তথ্যের লগ প্রদান করা উচিত, যাতে অতিরিক্ত অনুরোধ চিহ্নিত করা যায়
• EUDI: ব্যবহারকারীরা লেনদেনের লগ অ্যাক্সেস করতে, সন্দেহজনক অনুরোধ রিপোর্ট করতে এবং মুছে ফেলার অনুরোধ করতে সক্ষম হওয়া উচিত

ধারণ শ্রেণী প্রকাশ নীতিরই অংশ হওয়া উচিত:

• পুলিশের রাস্তার পাশ: আইনগত অপারেশনাল রেকর্ডের বাইরে ডিফল্টভাবে কোনো ধারণ নেই
• রেন্টাল প্রি-চেক: বুকিংয়ের সাথে সংযুক্ত লেনদেনের রেকর্ড, পুনরায় ব্যবহারযোগ্য পরিচয়ের কপি নয়
• নিয়োগকর্তার ফ্লিট কমপ্লায়েন্স: কমপ্লায়েন্স রেকর্ড বা প্রত্যয়নের ফলাফল, কাঁচা শংসাপত্র ডেটা নয়
• বীমাকারীর দাবি: দাবিতে সীমাবদ্ধ দাবির রেকর্ড, স্থায়ী অ্যাক্সেস নয়

ধারণ উপেক্ষা করা একটি ভবিষ্যত IDP কেবল আংশিকভাবে গোপনীয়তা-সংরক্ষণকারী।

ওয়ালেটের আসলে কী সিদ্ধান্ত নেওয়া উচিত

যদি আমাকে এই পুরো নিবন্ধটি একটি বাস্তবায়ন নিয়মে সংকুচিত করতে হয়, তাহলে এটি হবে:

ওয়ালেটের উত্তর দেওয়া উচিত নয় “আমি কি এই শংসাপত্র উপস্থাপন করতে পারি?” বরং উত্তর দেওয়া উচিত “আমি কি এই প্রমাণীকৃত যাচাইকারীর কাছে, এই উদ্দেশ্যমূলক ব্যবহারের জন্য, এই প্রসঙ্গে, এই ধারণ শ্রেণীর অধীনে এই সেট দাবিগুলো উপস্থাপন করতে পারি?”

সেই সিদ্ধান্তটি কমপক্ষে এই ইনপুটগুলো দ্বারা চালিত হওয়া উচিত:

• যাচাইকারীর পরিচয়
• যাচাইকারীর বিভাগ
• উদ্দেশ্যমূলক ব্যবহার
• নিবন্ধিত অ্যাট্রিবিউট সুযোগ
• ইস্যুকারীর প্রকাশ নীতি, যদি উপস্থিত থাকে
• পরিবেশ (রাস্তার পাশ, পিকআপ, রিমোট, ফ্লিট, দাবি)
• ধারকের অনুমোদন
• প্রযোজ্য ধারণ নীতি

মানদণ্ডগুলো ইতিমধ্যেই এর জন্য অনেক যন্ত্রপাতি ধারণ করে: নির্বাচনী প্রকাশ, নির্ভরকারী-পক্ষ প্রমাণীকরণ, নিবন্ধিত উদ্দেশ্যমূলক ব্যবহার, অ্যাক্সেস সার্টিফিকেট, প্রকাশ নীতি মূল্যায়ন এবং উদ্দেশ্য-সীমাবদ্ধ অনুরোধ। এখনও যা অনুপস্থিত তা হলো সেই টুকরোগুলোকে একটি সুসংগত প্রকাশ আর্কিটেকচার হিসেবে বিবেচনা করার শৃঙ্খলা।

মূল যুক্তি

ভবিষ্যতের IDP-এর জিজ্ঞাসা করা উচিত নয় ডেটা প্রকাশ করা যাবে কিনা। বরং জিজ্ঞাসা করা উচিত:

• কে জিজ্ঞাসা করছে?
• কোন উদ্দেশ্যে?
• কোন কর্তৃপক্ষের অধীনে?
• কোন প্রসঙ্গে?
• কোন ধারণ পরিণতি সহ?

পুলিশ, রেন্টাল ডেস্ক, নিয়োগকর্তা এবং বীমাকারীরা একটি অনুরোধের অন্য প্রান্তে চারটি লোগো নয়। তারা চারটি ভিন্ন ঝুঁকির মডেল, চারটি ভিন্ন আইনি প্রসঙ্গ, জিজ্ঞাসার চারটি ভিন্ন কারণ — এবং তাদের চারটি ভিন্ন প্রকাশ সেট তৈরি করা উচিত।

এটি অপ্রয়োজনীয় জটিলতা নয়। একটি আধুনিক ড্রাইভিং শংসাপত্র এরকমই দেখায় যখন এটি প্রতিটি যাচাইকারীকে একই যাচাইকারী হিসেবে বিবেচনা করা বন্ধ করে দেয়।