DAT (Distributed Access Token) ​

1. পরিচিতি ​

একযোগে সংযুক্ত ব্যবহারকারীর সংখ্যা বাড়ার সাথে সাথে সেশনের (Session) সংখ্যাও বাড়ে এবং সেশন সার্ভারে অতিরিক্ত চাপ তৈরি হয়।

DAT হলো এই সেশন সার্ভারের চাপের সমস্যা সমাধান করে সার্ভারগুলোর মধ্যে অবস্থা ভাগ না করে (Stateless) দক্ষ প্রমাণীকরণ বাস্তবায়নের জন্য পরিকল্পিত একটি টোকেন স্পেসিফিকেশন।

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

2. ওয়্যার ফরম্যাট ​

expire . cid . plain . secure . signature

2.1. ফিল্ড অনুযায়ী বিস্তারিত স্পেসিফিকেশন ​

মেয়াদ শেষের সময় : uint64 (Unix Time)

• টোকেনের মেয়াদ শেষের সময় সেকেন্ড (Seconds) এককে 64-বিট আনসাইনড পূর্ণসংখ্যা হিসেবে প্রকাশ করে।
• কেবল বিশুদ্ধ দশমিক সংখ্যা গ্রহণযোগ্য। চিহ্ন, স্পেস বা বিভাজক থাকলে সেটি ফরম্যাট ত্রুটি।

CID : Hex (uint64)

• টোকেন যাচাইয়ে ব্যবহৃত সার্টিফিকেট ID (Certificate ID)।
• কেবল বিশুদ্ধ হেক্সাডেসিমাল সংখ্যা গ্রহণযোগ্য, এবং 0x প্রিফিক্স ব্যবহার করা হয় না।

সাধারণ ডেটা : Base64Url (Binary)

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

এনক্রিপ্টেড ডেটা : Base64Url (Binary)

• ক্লায়েন্টের কাছে গোপন রাখার ডেটা ধারণ করে। সার্টিফিকেটের এনক্রিপশন অ্যালগরিদম দিয়ে এনক্রিপ্ট করা থাকে, তাই সার্টিফিকেট নেই এমন ক্লায়েন্ট এর বিষয়বস্তু ডিক্রিপ্ট করতে পারে না।
• ভিতরের কাঠামো IV(96bit) + সাইফারটেক্সট, এবং প্রতিবার এনক্রিপশনে IV নতুন করে তৈরি হয়।

স্বাক্ষর : Base64Url (Binary)

• টোকেনের জালিয়াতি ও পরিবর্তন যাচাইয়ের জন্য স্বাক্ষর ডেটা। আগের ফিল্ডগুলোকে সার্টিফিকেটের স্বাক্ষর অ্যালগরিদম দিয়ে স্বাক্ষর করে তৈরি করা হয়।
• স্বাক্ষর যাচাইয়ে ব্যর্থ টোকেনের কোনো ফিল্ডকেই বিশ্বাস করা উচিত নয়।

3. ক্যানোনিকাল নিয়ম (Canonical Rules) ​

একাধিক ভাষায় লেখা ক্লায়েন্ট যেন একই টোকেন একইভাবে ব্যাখ্যা করে, তার জন্য নিচের নিয়মগুলো ইমপ্লিমেন্টেশনভেদে ভিন্ন হওয়া চলবে না। রেফারেন্স ইমপ্লিমেন্টেশন হলো Rust (dat-rust), এবং বাকি সব ইমপ্লিমেন্টেশন এই নিয়মের সাথে মিলিয়ে তৈরি।

3.1. সংখ্যাসূচক ফিল্ডের পার্সিং ​

expire ও cid কঠোরভাবে ব্যাখ্যা করা হয়। নিচের সব ইনপুট ফরম্যাট ত্রুটি হিসেবে প্রত্যাখ্যাত হয়।

3.2. মেয়াদ শেষের নির্ধারণ ​

DAT টোকেন ও সার্টিফিকেটের মেয়াদ শেষের সীমানা একে অপরের থেকে আলাদা। এ দুটি গুলিয়ে ফেলবেন না।

টোকেন মেয়াদ শেষের মুহূর্তেই তৎক্ষণাৎ অকার্যকর হয়, আর সার্টিফিকেট সেই মুহূর্ত পর্যন্ত বৈধ থাকে। সীমানায় ইস্যু হওয়া টোকেন যাচাই করতে হলে সার্টিফিকেটকে টোকেনের চেয়ে এক টিক বেশি বেঁচে থাকতে হয়।

3.3. খালি secure পেলোড ​

এনক্রিপ্ট করার মতো ডেটা না থাকলে secure হয় একটি খালি স্ট্রিং।

• encrypt(খালি ইনপুট) → খালি আউটপুট (IV বা GCM ট্যাগ কিছুই যুক্ত হয় না)
• decrypt(খালি ইনপুট) → খালি আউটপুট
• খালি না হয়েও IV-এর দৈর্ঘ্যের (12 বাইট) সমান বা ছোট হলে সেটি ডিক্রিপশন ত্রুটি।

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ secure-এর জায়গা খালি — এটি একটি স্বাভাবিক টোকেন

4. ইস্যু ও যাচাই ​

4.1. ইস্যু প্রক্রিয়া ​

1. ম্যানেজারের কাছে থাকা সার্টিফিকেটগুলোর মধ্য থেকে ইস্যুযোগ্য (issuable) সার্টিফিকেট বেছে নেওয়া হয়।
2. expire = now + dat_ttl_seconds হিসাব করা হয়।
3. plain কে Base64Url-এ এনকোড করা হয়, এবং secure কে এনক্রিপ্ট করার পর Base64Url-এ এনকোড করা হয়।
4. expire.cid.plain.secure স্ট্রিংয়ে স্বাক্ষর করে সেটি শেষ ফিল্ড হিসেবে যুক্ত করা হয়।

4.2. যাচাই প্রক্রিয়া ​

1. বিন্দু (.) দিয়ে 5টি ফিল্ডে ভাগ করা হয়। ফিল্ডের সংখ্যা ভিন্ন হলে সেটি ফরম্যাট ত্রুটি।
2. expire পরীক্ষা করা হয়। মেয়াদোত্তীর্ণ টোকেন স্বাক্ষর যাচাইয়ের আগেই প্রত্যাখ্যাত হয়।
3. cid দিয়ে সার্টিফিকেট খোঁজা হয়। না পাওয়া গেলে যাচাই সম্ভব নয়।
4. expire.cid.plain.secure অংশের উপর স্বাক্ষর যাচাই করা হয়।
5. যাচাই সফল হওয়ার পরই কেবল secure ডিক্রিপ্ট করা হয়।

5. JWT-এর সাথে তুলনা ​

DAT এবং JWT (JSON Web Token) বিন্দু (.) দিয়ে বিভক্ত টোকেন কাঠামো ও স্বাক্ষরের মাধ্যমে যাচাইয়ের পদ্ধতি ভাগ করে নেয়, তবে ভিতরের ডিজাইনে নিচের মূল পার্থক্যগুলো রয়েছে।

5.1. কাঠামোগত পার্থক্যের তুলনা ​

• JWT কাঠামো

  header	body	signature
  Base64Url (JSON String)	Base64Url (JSON String)	Base64Url (Binary)

• DAT কাঠামো

  মেয়াদ শেষের সময়	CID	সাধারণ ডেটা	এনক্রিপ্টেড ডেটা	স্বাক্ষর
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. মূল পার্থক্যসমূহ ​

• Binary ভিত্তিক হালকাকরণ: JWT, Header ও Body-কে JSON স্ট্রিং আকারে পরিচালনা করে, কিন্তু DAT বাইনারি (Binary) ডেটা সরাসরি পরিচালনা করে ডেটার আকার সর্বোত্তম করে এবং পার্সিং দক্ষতা বাড়ায়।
• নিরাপত্তা অন্তর্নির্মিত (এনক্রিপ্টেড ডেটা ফিল্ড): JWT-এ পেলোড (Payload) মূলত সাদা টেক্সট আকারে উন্মুক্ত থাকে, তাই এনক্রিপশন দরকার হলে JWE-এর মতো আলাদা স্পেসিফিকেশন প্রয়োগ করতে হয়। অন্যদিকে DAT এনক্রিপ্টেড ডেটা ফিল্ডের মাধ্যমে টোকেন নিজেই এনক্রিপশন সুবিধা দেয়।
• মেয়াদ শেষের সীমা বাধ্যতামূলক: JWT-এ exp (Claims) ফিল্ড ঐচ্ছিক, কিন্তু DAT-এ মেয়াদ শেষের সময় ফিল্ড টোকেন কাঠামোতেই বাধ্যতামূলক, ফলে মেয়াদ যাচাই অবশ্যই সম্পাদিত হয়।
• অ্যালগরিদম নিয়ে দর-কষাকষি নেই: JWT হেডারের alg মান টোকেন নিজেই বহন করে বলে অ্যালগরিদম কনফিউশন আক্রমণের আক্রমণ-পৃষ্ঠ তৈরি হয়। DAT-এ অ্যালগরিদম সার্টিফিকেট নির্ধারণ করে এবং টোকেনের ভিতরে অ্যালগরিদমের কোনো তথ্য থাকে না।