DAT (Distributed Access Token) ​

DAT প্রবর্তনের পটভূমি ​

আজকাল অনেক সিস্টেম JWT গ্রহণ করেছে, কিন্তু বাস্তব পরিচালন পরিবেশে নিচের মতো কাঠামোগত সীমাবদ্ধতা বিদ্যমান।
এগুলো সমাধানের জন্যই নতুন টোকেন স্পেসিফিকেশন DAT ডিজাইন করা হয়েছে।

🧩 নিরাপত্তা স্পেসিফিকেশনের বিভক্ততা ও বাধ্যবাধকতার অভাব ​

JWT, JWE-এর মতো এনক্রিপশন স্ট্যান্ডার্ড দেয়, কিন্তু সেগুলোর ব্যবহার বাধ্যতামূলক নয়।
ফলে অনেক ডেভেলপমেন্ট পরিবেশে এনক্রিপশন বাদ দেওয়া হয় বা অ-মানক পদ্ধতিতে ডেটা পাঠানো হয়, যা নিরাপত্তা দুর্বলতা তৈরি করে।

🔑 স্ট্যাটিক কী (Static Key) ব্যবহারের নিরাপত্তা ঝুঁকি ​

স্বাক্ষর কী-এর রোটেশন (Key Rolling) বাধ্যতামূলক না হওয়ায় একটিমাত্র কী দীর্ঘকাল ধরে ব্যবহারের ঘটনা প্রায়ই ঘটে। কী চুরি হলে এটি সম্পূর্ণ সিস্টেমের নিরাপত্তা ধসের কারণ হতে পারে; বাস্তবে বড় ই-কমার্স সাইটে এর কারণে নিরাপত্তা লঙ্ঘনের ঘটনা ঘটেছে।

📉 ওভারহেডের কারণে কর্মক্ষমতা হ্রাস ​

JWT প্রতিটি অনুরোধে JSON পার্সিং প্রক্রিয়ার মধ্য দিয়ে যায় এবং উল্লেখযোগ্য পরিমাণ CPU রিসোর্স খরচ করে। উচ্চ কর্মক্ষমতা প্রয়োজন এমন পরিবেশে এই পার্সিং খরচ পুরো সিস্টেমের বাধা (bottleneck) হয়ে দাঁড়াতে পারে।

DAT-এর মূল দর্শন ​

DAT ডিজাইন করা হয়েছে এই নীতির উপর ভিত্তি করে যে নিরাপত্তা ঐচ্ছিক নয় বরং বাধ্যতামূলক হওয়া উচিত, এবং কর্মক্ষমতার সাথে আপস করা যায় না।

⚡ হালকা ও দ্রুত ​

উপরে দেখানো অনুযায়ী DAT-এ বিন্দু (.) দিয়ে বিভক্ত মাত্র পাঁচটি নির্দিষ্ট ফিল্ড থাকে। ফিল্ডের অবস্থান স্পেসিফিকেশনেই নির্ধারিত, তাই JSON পার্সিং ছাড়াই কেবল বিভাজক খুঁজে প্রতিটি মান কেটে নেওয়া যায়।

🔐 বাধ্যতামূলক নিরাপত্তা ​

DAT ডেটা পাঠানোর সময় সাধারণ (Plain) ও এনক্রিপ্টেড (Secure) অঞ্চলকে ভৌতভাবে আলাদা করে।
সংবেদনশীল তথ্য অবশ্যই এনক্রিপ্ট করতে হবে — এটি বাধ্যতামূলক, এবং পুরো প্রক্রিয়া সার্টিফিকেটে ঘোষিত মানসম্মত অ্যালগরিদম (ECDSA, AES-GCM ইত্যাদি) দিয়ে সুরক্ষিত।

এনক্রিপশন অ্যালগরিদম টোকেন নয়, সার্টিফিকেট নির্ধারণ করে। টোকেনের ভিতরে অ্যালগরিদমের কোনো তথ্য থাকে না, তাই JWT-এর alg হেডার থেকে উদ্ভূত অ্যালগরিদম কনফিউশন আক্রমণের আক্রমণ-পৃষ্ঠ এখানে নেই।

🔄 বাধ্যতামূলক কী রোলিং ​

DAT সার্টিফিকেট শুধু টোকেন ইস্যু ও মেয়াদ শেষ নয়, কী-এর জীবনচক্রও সরাসরি পরিচালনা করে।
"কখন থেকে কখন পর্যন্ত ইস্যু করা যাবে" — এটি সার্টিফিকেটে স্পেসিফিকেশন স্তরেই গাঁথা থাকে, তাই সেই মেয়াদ পার হলে ওই সার্টিফিকেট দিয়ে নতুন টোকেন তৈরি করা যায় না। প্রশাসকের অসাবধানতায় একটি কী কয়েক বছর ধরে ব্যবহৃত হওয়ার পরিস্থিতি কাঠামোগতভাবেই ঘটে না।

⏱️ ইস্যু-মেয়াদ ও বৈধতার মেয়াদের পৃথকীকরণ ​

"সার্টিফিকেট যতক্ষণ টোকেন ইস্যু করতে পারে সেই মেয়াদ" এবং "ইস্যু হওয়া টোকেন যতক্ষণ বেঁচে থাকে সেই মেয়াদ" — এ দুটি আলাদা মান।
এর ফলে সার্টিফিকেট ইস্যু বন্ধ করার পরও ইতিমধ্যে বেরিয়ে যাওয়া টোকেন নিজের আয়ু পূর্ণ করতে পারে, আর সেই সময়ের মধ্যেই ক্লাস্টার স্বাভাবিকভাবে পরবর্তী সার্টিফিকেটে সরে যায়।

প্রমাণীকরণ ব্যবস্থার তুলনা ​

পারফরম্যান্স ​

পরবর্তী ডকুমেন্ট ​

• DAT — টোকেনের ওয়্যার ফরম্যাট ও ক্যানোনিকাল নিয়ম
• সার্টিফিকেট — সার্টিফিকেটের কাঠামো, অ্যালগরিদম, জীবনচক্র
• CMS সিঙ্ক — সার্টিফিকেট বিতরণ ও পরিচালনার সময় যে আচরণগুলো জানা দরকার